[Python-3000] [Python-Dev] PEP 367: New Super

[Guido van Rossum]

On 5/31/07, Tim Delaney <timothy.c.delaney at gmail.com> wrote:
> Guido van Rossum wrote:
> > I've updated the patch; the latest version now contains the grammar
> > and compiler changes needed to make super a keyword and to
> > automatically add a required parameter 'super' when super is used.
> > This requires the latest p3yk branch (r55692 or higher).
> >
> > Comments anyone? What do people think of the change of semantics for
> > the im_class field of bound (and unbound) methods?
>
> I had problems getting the p3yK branch that I only resolved yesterday so I
> haven't actually applied the patch here yet. Turns out I'd grabbed the wrong
> URL for the repository at some point, and couldn't work out why I kept
> getting prop not found errors when trying to check out.

svn definitely has some sharp edges when you specify a bad URL.

> If I understand correctly, the patch basically takes im_class back to Python
> 2.1 semantics, which I always felt were much more useful than the 2.2
> semantics. As a bonus, it should mean that the repr of a bound or unbound
> method should reflect the class it was defined in. Is this correct?

Right. (I think that's the main cause of various test failures, which
I haven't corrected yet.)

> The patch notes say that you're actually inserting a keyword-only argument -
> is this purely meant to be a stopgap measure so that you've got a local
> (which could be put into a cell)?

I'm not using a cell because I'm storing the result of calling
super(Class, self) -- that is different for each instance, while a
cell would be shared by all invocations of the same function.

> Presumably with this approach you could
> call the method like:
>
>     A().func(1, 2, super=object())

No, because that would be a syntax error (super as a keyword is only
allowed as an atom). You could get the same effect with

  A().func(1, 2, **{'super': object()})

but that's so obscure I don't mind.

Hmm, right now the super=object() syntax *is* accepted, but that's a
bug in the code (which I submitted yesterday) that checks for
assignments to keywords like None, True, False, and now super.

> The final implementation IMO needs to have super be an implicit local, but
> not an argument.

I thought so to at first, but there are no APIs to pass the value
along from the point where the super object is created (in the
method_call() function) to the point where the frame exists into which
the object needs to be stored (in PyEval_EvalCodeEx). So I think a
hidden keyword argument is quite convenient.

> BTW, what made you change your mind on re-using im_class? Previously you'd
> said you didn't want to (although now I can't find the email to back that
> up). I'd written off reusing it for this purpose because of that.

I do recall not liking that, but ended up thinking some more about it
after I realized how much work it would be to add another member to
the method struct. When I tried it and saw that only 7 unit test
modules had failures (and mostly only a few out of many tests) I
decided it was worth trying.

> I won't be able to update the PEP until Sunday (visiting family) but I'll
> try to incorporate everything we've discussed. Did we get a decision on
> whether im_class should return the decorated or undecorated class, or did
> you want me to leave that as an open issue?

In my implementation, it will return whatever object is found in the
MRO of the derived class, because that's all that's available  -- I
suppose this means in practice it's the decorated class.

BTW I'm open to a different implementation that stores the class in a
cell and moves the computation of super(Class, self) into the function
body -- but that would be completely different from the current
version, as the changes to im_class and method_call would not be
useful in that case. Instead, someting would have to be done with that
cell at class definition time. I fear that it would be much more
complicated to produce that version -- I spent a *lot* of time trying
to understand how symtable.c and compile.c work in order to be able to
add the implied super argument. That code is really difficult to
follow, it uses a different style than most of the rest of Python
(perhaps because I didn't write it :-), and it is quite subtle. For
example, if a nested function inside a method uses super, this
currently doesn't reference the super of the method -- it adds super
to the nested function's parameter lists, and this makes it
effectively uncallable.

> I'm starting to feel somewhat embarrassed that I haven't had the time
> available to work solidly on this, but don't let that stop you from doing
> it - I'd rather have a good implementation early and not let my ego get in
> the way <wink>.

Thanks. I realize I sort of took over and was hoping you'd respond
like this. I may not have much time over the weekend (recovering from
an exhausting and mind-bending trip to Beijing) so you're welcome to
catch up!

> Cheers,
>
> Tim Delaney

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