> Hmm, I don't like these class methods, but it would probably
> help with the problem...
>
> from mx.DateTime import DateTime
>
> dt1 = DateTime(2001,1,16)
> dt2 = DateTime.From("16. Januar 2001")
>
> Still looks silly to me... (I don't like these class methods).
Maybe it's time you started to like them. :-)
> > I've been thinking about this. I don't think that's quite the right
> > protocol; I don't want to complicate the DECREF macro any more. I
> > think that tp_dealloc must call tp_del and then decide whether to
> > proceed depending on the refcount.
>
> Have you tried to move the decref action into a separate function
> (which is only called in case the refcount reaches 0) ? I think
> that this could in fact enhance the overall performance since
> the compiler can then decide whether or not to inline the relevant
> code.
>
> I wonder what the impact would be...
My gut tells me that the compiler will usually *not* inline it, and
then it will slow deallocation down by one extra function call. And
if the compiler *does* inline it, it's code bloat. So either way you
lose, my gut tells me. (The dealloc functions for most common types
are very fast and I would hate to see them slow down.)
> Good, so overriding the tp_alloc/free slots is generally not
> a wise thing to do, I guess.
If the base type has a custom free list (like the int type does), you
*have* to override it if the instances of the subtype are larger than
the base type. Currently int doesn't allow subtyping yet because I
haven't refactored its code in this area yet.
> > > - Could the generic APIs perhaps fall back to tp_getattr to make
> > > the transition from classic types to base types a little easier ?
> >
> > I'd rather not: that would prevent discovery of attributes supported
> > by the classic tp_getattr. The beauty of the new scheme is that *all*
> > attributes (methods and data) are listed in the type's __dict__.
>
> Uhm, I think you misunderstood me: tp_getattr is not used anymore
> once the Python interpreter finds a tp_getattro slot
> implementation, so there's nothing to prevent ;-):
>
> PyObject_GetAttr() does not use tp_getattr if tp_getattro is
> defined, while PyObject_GetAttrString() prefers tp_getattr over
> tp_getattro -- something is not symmertic here !
>
> As a result, dir() finds the __members__ attribute which lists
> the attributes (it uses PyObject_GetAttrString(), but
> instance.attribute does not work because it uses PyObject_GetAttr().
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.
Apparently you left your tp_getattr implementation in place but added
PyObject_GenericGetAttr to the tp_getattro slot -- this simply doesn't
follow the rules.
--Guido van Rossum (home page: http://www.python.org/~guido/)
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