On 4/29/07, Delaney, Timothy (Tim) <tdelaney@avaya.com> wrote:

I think the current PEP draft is way too complicated - I don't think there's any need for descriptors, etc. I think we can make things work in the following way:

1. When a method is defined, the class is bound to it via an attribute (which in my version is called func_class).

In Py3k all the func_XXX attrs are renamed __XXX__, so this would be __class__; but that's a name reserved for something else, so it would need to be something else. E.g. __containing_class__. Also, this would have to be done when the class is defined; when the method is being defined the class doesn't exist yet.

2. Every non-static method has an implicit cell variable called 'super'.

I think you're using 'cell' in a different sense than it is normally used in Python's implementation. What you are looking for is called a local variable (I deduce this from your initialization of the "cell" with something computed from the first argument). A 'cell' (as I introduced in my original back-of-the-envelop proposal; apparently you totally missed this reference) is a special kind of object containing a reference to another object and used to implement nonlocal variable references (the Python 2 read-only nonlocals as well as the Python 3 writable nonlocals). The cell is initialized in the surrounding scope and attached to the function object (as func_closure in 2.x, or __closure__ in 3.0). When the function is called, a reference to the cell is stored in the call frame. If anything in your proposal resembles a cell (in the sense that I and other Pythonistas mean it), it's the func_class attribute. In fact, in this sense our proposals are equivalent modulo slight implementation details; I proposed using a cell because there's an existing mechanism to get these mapped into a local variable, and because cells are cheaper than function attributes -- the first function attribute requires creating a dict, which is one of the larger built-in objects.

This would preferably not be able to be rebound. I also think it would be beneficial if the first parameter to the method couldn't be rebound (point 7 in my original email in this thread).

The latter part sounds irrelevant to me.

3. When a method is entered, the 'super' cell variable is populated by a call equivalent to:

super = __builtin__.super(func_class, first_parameter)

This would result in 'super' being a constant object, within the scope of the currently-executing method. 'keyword' was perhaps too strong - I was thinking this would only need to be done if 'super' were actually used, which would be easier to determine if 'super' actually were a keyword. This could still be done by not emitting the above call unless the 'super' cell variable were ever actually used.

This sounds about right to me, with the strong preference that super *should* be made a keyword, and the built-in of the same name renamed to __super__, as it has a somewhat similar relationship to the super keyword as the built-in __import__ has to the import keyword.

I've done bytecode-hacky stuff to do the equivalent of the above (as much as I've been able to), but a real implementation would just emit the correct bytecode (or java bytecode, or whatever) in the compiled code object.

Shouldn't be too hard for someone who's hacked Python/compile.c before.

The issue of super() vs. super.__call__() ambiguity - I'll need to look at that when I get home.

Sounds irrelevant -- if super is equivalent to __builtin__.__super__(<class>, <firstarg>) then super never gets called; the only thing ever done to it (in the normal course of things) is to request an attribute of it.

I'm a strong -1 against super() automatically passing the parameters that were passed to the currently-executing method.

Same here. There seems to be the remaining controversy that there are three forms of super calls currently in use: super(ThisClass, self).method(...) # in a regular method super(ThisClass, cls).method(...) # in a class method super(ThisClass).method(...) # ??? The first two are handled by your "use the first argument" approach. The third exists so that you can create an "unbound" super instance which is useful for the oft-misunderstood autosuper example in my "descrintro" essay: http://www.python.org/download/releases/2.2.3/descrintro/#metaclass_examples . But since the latter is the hack that we're trying to replace with a proper implementation here, I suspect we can get away with only supporting the first two forms (and the third form is still supported using __builtin__.__super__). IOW I think you're on to something. Keep up the good word. -- --Guido van Rossum (home page: http://www.python.org/~guido/)