[Python-3000] [Python-Dev] PEP 367: New Super (original) (raw)

Guido van Rossum guido at python.org
Thu May 31 15:08:16 CEST 2007

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 imclass 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 imclass 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 imclass? 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 imclass 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 .

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

More information about the Python-3000 mailing list