A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-July/016183.html below:

[Python-Dev] PEP 253: Subtyping Built-in Types

[Python-Dev] PEP 253: Subtyping Built-in TypesGuido van Rossum guido@digicool.com
Sun, 22 Jul 2001 22:40:27 -0400
> What I did was to enhance the base class' tp_alloc and tp_dealloc 
> APIs to only use the free list in case the type being passed to the
> APIs is a base type; in all other cases, standard processing takes
> place.
> 
> Perhaps ints could do the same ?

Yes, that's what I was planning to do.

> > 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 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).

--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