[Python-Dev] New flag to differentiate Builtins and extensions
Boris.Boutillier at arteris.net
Wed Nov 12 04:38:35 EST 2003
I look into the archives and didn't see any debate on the question, hope
I didn't miss something.
My point concerns limitations on extensions module due to checks aiming
The main point is settable extension classes.
In Python code there is some checks against TPFLAGS_HEAPTYPE, extension
modules should'nt have this flag, so the normal type->tp_setattro doesnt
allow the user to
set new attributes on your extension classes. There is a way around,
write a special MetaClass which redefine setattr.
In the extension module I'm writing (I'm porting some Python code to
Python-C for speed issues) the user can set attributes and slots on my
What I need is the complete type->tp_setattro behaviour, without the
check. I didn't see a way to have this behaviour using only Python API
(is rereadying the type a work around ?), so I copy paste all the code
to make update_slots work (ouch 2500 lines).
This is now almost working, every kind of attribute can be set but the
__setattr__ one, the hackcheck prevents the user from calling another
__setattr__ from its new setattr:
example of my extension class hierachy:
In the extension, there is a tp->setattro on B, if the user want to
redefine it, he can't call the A __setattr__:
## Do here my special stuff
This won't work, the hachcheck will see some kind of hack here, 'you
cant' call the A.__setattr__ function from a B object' .
First question, Is there a known way around ?
Possible Improvments :
In the python code there is in function function checks to see if you
are not modying builtins classes, unfortunately this code is also
concerning extension modules.
I think the Heaptype flag is abusively used in differents cases mostly,
in type_setattro, object_set_bases, object_set_classes, the checks have
nothing to do with the HeapType true definition as stated in the
comments in Include/Object.h , it is used, I think, only because this is
the only one that makes a difference between builtins and user classes.
Unfortunately with this flag extension classes fall into the
A way to solve the problem without backward compatibility problems,
would be to have a new TPFLAGS_SETABLE flag, defaulting to 0 for
builtins/extension classes and 1 for User,Python classes. This flag
would be check in place of the heaptype one when revelant.
I'm ready to write the code for this if there is some positive votes,
won't bother if everybody is against it.
More information about the Python-Dev