PyCheck for a classes defined in python and user data in PyObject_HEAD

[sndive]

q#1:
in C I want to check if a given PyObject is a xml.dom.minidom .Node (or
a derivative).
how do i extract a PyTypeObject for such a class?

issue #2
I'm in a situation when i don't really need to extend python with any
classes of my own but
i do have extra luggage for the python data structures such as tuples,
lists, dictionaries, etc
on the c++ side. I see no place in PyObject_HEAD where i can stick a
void* to my extra data.
If i enter a feature request into bugzilla for python do you think it
will be well received?
#ifdefed of course like the prev/next extras.
I'm surprised noone else is using evil twin approach.
The reason i'm asking is because while for dictionaries i can stick
weak pointer back to my c++
object in a key with an obscure name while in lists this would change
the list size and thus
is obviously not as easy to "hide" from the client code.
a placeholder in a pyobject would've been of help here

[Gabriel Genellina]

En Fri, 16 Nov 2007 00:27:42 -0300, <sn****@gmail.c omescribió:

On Nov 1, 11:04 pm, "Gabriel Genellina" <[e-mail].a r>
wrote:

>En Thu, 01 Nov 2007 22:13:35 -0300, <snd...@gmail.c omescribió:

>I'm in a situation when i don't really need to extend python with any
classes of my own but
i do have extra luggage for the python data structures such as

tuples,

>lists, dictionaries, etc
on the c++ side. I see no place in PyObject_HEAD where i can stick a
void* to my extra data.

Assuming you can recompile all the extensions you use, you could insert
your void* into _PyObject_HEAD_ EXTRA and _PyObject_EXTRA _INIT

i added two void pointers to head_extra and 0,0, to the extra_init.
For some reason i get garbage in them from PyEval_EvalCode :-(
(that's after i blew the build dir and rebuilt 2.4.4 from scratch
so i don't think i have a bad build)

Can't you use instead the other approaches suggested on this thread? Like
keeping a weakkey dictionary holding your additional attributes? Seems a
lot safer to do that way.

I've never changed that headers myself so I can't guarantee it works.
Perhaps there are some assumptions somewhere in the code about a specific
layout. But since _PyObject_HEAD_ EXTRA is used in the debug build I think
you should be able to add your own fields, at least in principle...
Remember that this change invalidates ALL binaries for ANY library or
extension you may be using. An additional check might be to change the
Python release number to 2.9.9 or so, so none of your existing extensions
can inadvertidely be used.

--
Gabriel Genellina

[sndive]

On Nov 15, 10:00 pm, "Gabriel Genellina" <[e-mail].a r>
wrote:

En Fri, 16 Nov 2007 00:27:42 -0300, <snd...@gmail.c omescribió:

On Nov 1, 11:04 pm, "Gabriel Genellina" <[e-mail].a r>
wrote:

En Thu, 01 Nov 2007 22:13:35 -0300, <snd...@gmail.c omescribió:
I'm in a situation when i don't really need to extend python with any
classes of my own but
i do have extra luggage for the python data structures such as
tuples,
lists, dictionaries, etc
on the c++ side. I see no place in PyObject_HEAD where i can stick a
void* to my extra data.

Assuming you can recompile all the extensions you use, you could insert
your void* into _PyObject_HEAD_ EXTRA and _PyObject_EXTRA _INIT

i added two void pointers to head_extra and 0,0, to the extra_init.
For some reason i get garbage in them from PyEval_EvalCode :-(
(that's after i blew the build dir and rebuilt 2.4.4 from scratch
so i don't think i have a bad build)

Can't you use instead the other approaches suggested on this thread? Like
keeping a weakkey dictionary holding your additional attributes? Seems a
lot safer to do that way.

I've never changed that headers myself so I can't guarantee it works.
Perhaps there are some assumptions somewhere in the code about a specific
layout. But since _PyObject_HEAD_ EXTRA is used in the debug build I think
you should be able to add your own fields, at least in principle...

i finally found that i need to reset my fields in _Py_NewReferenc e(op)
also.
weakref approach won't work for me because i need extra data in lists/
dictionaries/tuples in addition to instances of classes
(all instances of all classes: can't derive and essentially
make my own bloated psl to maintain)

Remember that this change invalidates ALL binaries for ANY library or
extension you may be using. An additional check might be to change the

that's not a problem since i build with a prefix other than /usr/local
and the target is an embedded system so i have full control over
the environment (until someone cracks it :-)

i finally got most of the code working after i figured out that
HEAD_INIT is ignored by tuple allocation code, etc
and _Py_NewReferenc e has to be modified.

thank all of you for all the help. you got me unstuck.