[Python-3000] Abilities / Interfaces

Jim Jewett jimjjewett at gmail.com
Sun Nov 26 22:47:02 CET 2006


On 11/22/06, Guido van Rossum <guido at python.org> wrote:
> On 11/22/06, Walter Dörwald <walter at livinglogic.de> wrote:
> > Another effect of __special__ methods is that they divide
> > the class namespace into two parts: The __special__ names
> > are those that have to be implemented to support core
> > Python interfaces, and the methods without underscores
> > are those that implement the "main aspect" of the
> > class.

> Well, there are plenty of examples of __special__ methods
> for other purposes than core Python interfaces,

The documentation explicitly reserves __*__ to the language.  You can
argue that some uses aren't core, but that still means __*__ isn't
appropriate for a random user-supplied aspect.  (And if it were, that
would lead to conflicts over attractive names like __log__.
__package_module__name__ might work, but ... starts to get hackish.)

> and plenty of core Python
> interfaces that don't use __special__ (dict.get(), list.append(),
> iter.next(), str.lower(), you get the idea.)

ermm... I'm not seeing any counterexamples just yet.  get, append, and
lower apply only to specific classes, and from there they get
generalized to the informal interfaces that those classes prototype.

Less obviously, this is true even of next.  __iter__ is the special
method, and after you have called it, you are operating on the
iterable it returns (which may be self).  next isn't generic to all
objects; only to those which implement iteration (result from a
previous call to __iter__).

> The *original* idea was for __special__ names to apply to
> anything that wasn't invoked using regular method notation:

By this original intent, next would indeed be special, as would
implementation of any generic functions -- but if 3rd-party
generic/extensible functions become common they probably will need a
way to carve out their own namespaces.

-jJ


More information about the Python-3000 mailing list