[Python-checkins] r54539 - in python/trunk: Lib/string.py Misc/NEWS Objects/typeobject.c

Guido van Rossum guido at python.org
Fri Mar 23 19:41:47 CET 2007


On 3/23/07, Jim Jewett <jimjjewett at gmail.com> wrote:
> (Please note that most replies should trim at least one list from the Cc)

[-dev, -ideas]

> On 3/23/07, guido.van.rossum <python-checkins at python.org> wrote:
> > Note: without the change to string.py, lots of spurious warnings happen.
> > What's going on there?
>
> I assume it was a defensive measure for subclasses of both Template
> and X, where X has its own metaclass (which might have an __init__
> that shouldn't be ignored).
>
> This is where cooperative classes get ugly.  You could argue that the
> "correct" code is to not bother making the super call if it would go
> all the way to object (or even type), but there isn't a good way to
> spell that.

*Correct* code knows whether it is defining or extending a method, so
it always knows whether to call the super method or not.

> > +        # A super call makes no sense since type() doesn't define __init__().
> > +        # (Or does it? And should type.__init__() accept three args?)
> > +        # super(_TemplateMetaclass, cls).__init__(name, bases, dct)
>
> In this particular case, you could define a type.__init__ that did
> nothing.  (If the signature were wrong, type.__new__ would have
> already caught it.  If __new__ and __init__ are seeing something
> different, then the change was probably intentional.)

No, super calls to __init__ may see different arguments than __new__.
I'm adding a type_init() that insists on the minimal (default)
signature and calls object.__init__() with no args (just in case
object.__init__() ever grows useful functionality :-).

> The problem isn't really limited to type.__init__ though.  You'll
> sometimes see similar patterns for __del__, close, save, etc.

Again, it seems to be caused by confusion about whether one is
defining or extending the method. This is probably not clearly
documented for __del__(), but the intention was that object does *not*
define __del__(). For close() and save() I would venture it is
definitely a bug in the application if they don't know whether they
are defining or extending it. You can't fix problems caused by muddled
thinking.

> The
> main difference is that they have to either catch an error or check
> first, since object doesn't have an implementation of those methods.
> object.__init__ doesn't really do anything either, except check for
> errors.  Getting rid of it should have the same effect as complaining
> about parameters.

Getting rid of what?

> The ideal solution (discussion of which probably ought to stay on
> python-ideas) might be to replace object.__init__ with some sort of
> PlaceHolder object  that raises an error *unless* called through a
> cooperative super.  This PlaceHolder would also be useful for
> AbstractBaseClasses/Interfaces.  PlaceHolder still wouldn't deal with
> the original concern of verifying that all arguments had already been
> stripped and used; but the ABCs might be able to.

Sounds more like something certain cooperative frameworks might want
to add than something the core language should provide.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-checkins mailing list