🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Allocating Memory In Python
Author
I''m wondering if there''s a way to ''allocate'' memory in Python? Do variables get allocated on the heap or stack by default? It would make sense if it was the heap, but just by the complexity of Python I can''t be sure, does anyone know?
And if it IS allocated on the stack, how do you use the heap instead? Is there some sort of Py_New() function? Thanks
Chris Pergrossi
My Realm | "Good Morning, Dave"
Since Python''s values are reference-counted and garbage-collected, I can''t see how they would be created on the stack.
That becomes especially true when you consider the Stackless implementation that decouples the Python stack from the C stack.
[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]
That becomes especially true when you consider the Stackless implementation that decouples the Python stack from the C stack.
[ Start Here ! | How To Ask Smart Questions | Recommended C++ Books | C++ FAQ Lite | Function Ptrs | CppTips Archive ]
[ Header Files | File Format Docs | LNK2001 | C++ STL Doc | STLPort | Free C++ IDE | Boost C++ Lib | MSVC6 Lib Fixes ]
Python objects are almost always on the heap, for the reason Fruny suggested (reference counting). Hence when you extend you almost always use PyObject* someobject.
I read somewhere that Python allocates stuff on the heap even if you do something like "print 1" (a PyObject integer pointing to 1 is declared on the heap)
As for Py_New, couldn't you just do
PyObject* pobj = new PyObject;
and then it would have to be created on the heap, no matter what the implementation?
EDIT: From the docs:
Most Python/C API functions have one or more arguments as well as a return value of type PyObject*. This type is a pointer to an opaque data type representing an arbitrary Python object. Since all Python object types are treated the same way by the Python language in most situations (e.g., assignments, scope rules, and argument passing), it is only fitting that they should be represented by a single C type. Almost all Python objects live on the heap: you never declare an automatic or static variable of type PyObject, only pointer variables of type PyObject* can be declared. The sole exception are the type objects ; since these must never be deallocated, they are typically static PyTypeObject objects.
There you go.
Dustin
[edited by - thedustbustr on August 8, 2003 9:55:04 AM]
I read somewhere that Python allocates stuff on the heap even if you do something like "print 1" (a PyObject integer pointing to 1 is declared on the heap)
As for Py_New, couldn't you just do
PyObject* pobj = new PyObject;
and then it would have to be created on the heap, no matter what the implementation?
EDIT: From the docs:
Most Python/C API functions have one or more arguments as well as a return value of type PyObject*. This type is a pointer to an opaque data type representing an arbitrary Python object. Since all Python object types are treated the same way by the Python language in most situations (e.g., assignments, scope rules, and argument passing), it is only fitting that they should be represented by a single C type. Almost all Python objects live on the heap: you never declare an automatic or static variable of type PyObject, only pointer variables of type PyObject* can be declared. The sole exception are the type objects ; since these must never be deallocated, they are typically static PyTypeObject objects.
There you go.
Dustin
[edited by - thedustbustr on August 8, 2003 9:55:04 AM]
Virtually all objects are allocated on the heap, IIRC. I think there are exceptions, though. Something to do with Python''s stack being coupled with the system stack. If you wanted some such object that is tied to the stack, there''s always copy/deepcopy.
Author
Hmm...makes sense. Cause what I want to do is, say, load a texture in Python, then pass that to my resource pool which would then keep the pointer. I just spotted a problem with that though, what's to keep Python from deleting that memory? Oh well, this may take some more thinking through. Got any ideas guys?
EDIT: and what I meant about Py_New wasn't meant for C++, but instead in Python do: 'x = new Texture()' as opposed to 'x = Texture()'
Chris Pergrossi
My Realm | "Good Morning, Dave"
[edited by - c t o a n on August 9, 2003 3:00:29 AM]
EDIT: and what I meant about Py_New wasn't meant for C++, but instead in Python do: 'x = new Texture()' as opposed to 'x = Texture()'
Chris Pergrossi
My Realm | "Good Morning, Dave"
[edited by - c t o a n on August 9, 2003 3:00:29 AM]
Author
Alright, I''ve found a solution (and thanked God for Boost :: Python in the process!). What I was trying to do was allocate memory in the script for usage in the main C++ application, but the problem with this is that Python is very protective of its memory, and doesn''t like anyone else touching it (and therefore HATES it when other people delete it!). Therefore, I allocate the memory in my engine, and pass a pointer back to Python (this conversion is automatically handled by Boost :D), which allows you to use it just like if it were allocated with ''new'' in Python. It even allows my memory manager to take care of the object if the script isn''t careful with it. So now instead of:
x = new resource.KTexture()
(which doesn''t work btw), I have:
x = resource.newTexture()
Pretty good no? Throughout this process, I also learned how to move C++ enumerated types into Python, and let me tell you that it is SO much easier to program now. For example, when I wanted to create a texture, I had to call it like this from the script (in C++ it''s got default arguments and enumerated types galore):
myTexture.CreateTexture( "My Texture", 300, 300, 0, 0, 21, 1 )
But with enumerated types, it becomes this:
myTexture.CreateTexture( "My Texture", 300, 300, 0, resource.usage.default, resource.format.R8G8B8A8, resource.pool.managed )
MUCH nicer, ya? Anyway, I''m just sharing this in the odd event someone else is having a similar problem or is thinking about this... But thanks for the help guys!
Chris Pergrossi
My Realm | "Good Morning, Dave"
x = new resource.KTexture()
(which doesn''t work btw), I have:
x = resource.newTexture()
Pretty good no? Throughout this process, I also learned how to move C++ enumerated types into Python, and let me tell you that it is SO much easier to program now. For example, when I wanted to create a texture, I had to call it like this from the script (in C++ it''s got default arguments and enumerated types galore):myTexture.CreateTexture( "My Texture", 300, 300, 0, 0, 21, 1 )
But with enumerated types, it becomes this:
myTexture.CreateTexture( "My Texture", 300, 300, 0, resource.usage.default, resource.format.R8G8B8A8, resource.pool.managed )
MUCH nicer, ya? Anyway, I''m just sharing this in the odd event someone else is having a similar problem or is thinking about this... But thanks for the help guys!
Chris Pergrossi
My Realm | "Good Morning, Dave"
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
