Guido van Rossum wrote: > > > > The simplified rule is that a type should only provide *either* > > > tp_getattr *or* tp_getattro, and likewise for set. The complete rule > > > is that if you insist on having both tp_getattr and tp_getattro, they > > > should implement the same semantics -- tp_getattr should be faster > > > when PyObject_GetAttrString() is called, and tp_getattro should be > > > faster when PyObject_GetAttr() is called. > > > > Ah, ok, didn't know that rule. > > Well, I just made it up today. :-) > > But it's a sensible rule, if you want predictable results. I'll implement it. > > I'll move to the new scheme for 2.2 then and leave the old tp_getattr > > around for backward compatibility. > > You should #ifdef on the Python version, unless you make your > tp_getattr do everything that tp_getattro does (possibly by calling on > the latter). Sure; that was my plan. I have to maintain 1.5.2 compatibility for the packages, that's why I'm trying to keep code redundancy minimal in the code base. So far, that has worked rather well (except for the attribute lookup part). About the typeobject.h struct names: could you tell me the Py-prefixed names of the getset et al. lists ? I'd rather not use the current non-prefixed names. Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4