[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