Re: [Python-Dev] New Super PEP
Dino Viehland wrote: Just to chime in from the IronPython side (better late than never I suppose): If we need to get access to the frame which is calling super then we can make that happen in IronPython. It just means that super gets treated like we treat eval today and won't work if it's been aliased. Being able to access the calling frame from IronPython would be really useful... Michael Foord http://www.voidspace.org.uk/ironpython/index.shtml -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Spealman Sent: Sunday, April 29, 2007 12:31 PM To: Collin Winter Cc: Python Mailing List Subject: Re: [Python-Dev] New Super PEP On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: What if the instance isn't called self? PEP 3099 states that self will not become implicit; it's talking about method signatures, but I think that dictum applies equally well in this case. I don't use the name self. I use whatever the first argument name is, found by this line of python code: instance_name = calling_frame.f_code.co_varnames[0] So I can't use super with anything but the method's invocant? That seems arbitrary. This will be added to the open issues, but it comes back to the problem with allow the exact same super implementation both operate in the super(Class, Object).foo() form and also the super.__call__() form in the new version. Any suggestions are welcome for how to solve this. Also, it's my understanding that not all Python implementations have an easy analogue to CPython's frames; have you given any thought to whether and how PyPy, IronPython, Jython, etc, will implement this? I'll bring this up for input from PyPy and IronPython people, but I don't know any Jython people. Are we yet letting the alternative implementations influence so strongly what we do in CPython? I'm not saying screw them, just pointing out that there is always a way to implement anything, and if its some trouble for them, well, 2.6 or 3.0 targetting is far down the road for any of them yet. It's a smell test: if a given proposal is unduly difficult for anything but CPython to implement, it's probably a bad idea. The language shouldn't go down the Perl 5 road, where python (the C interpreter) becomes the only thing that can implement Python (the language). Understandable. I still haven't contacted anyone about it on in the PyPy or IronPython worlds, and anyone familiar with Jython who can comment would be appreciated. Ditto for PyPy and IronPython, even though I should be able to find some information there myself. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/dinov%40microsoft.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Being able to access the calling frame from IronPython would be really
useful...
We do have a -X:Frames option but it's going to hurt your performance, but for
example:
IronPython 1.0.60816 on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
def f():
... x = locals
... print x()
...
f()
{'__name__': '__main__', '__builtins__': type '__builtin__', '__doc__': None,
'site': module 'site' from 'C:\Product\Released\IronPython-1.0\Lib\site.py', '
f': function f at 0x002B}
^Z
C:\Product\Released\IronPython-1.0.\ipy.exe -X:Frames
IronPython 1.0.60816 on .NET 2.0.50727.312
Copyright (c) Microsoft Corporation. All rights reserved.
def f():
... x = locals
... print x()
...
f()
{'x': built-in function locals}
^Z
But then we'll NEVER use the CLR stack for storing locals, but we can also
always get the calling frames.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Just to chime in from the IronPython side (better late than never I suppose): If we need to get access to the frame which is calling super then we can make that happen in IronPython. It just means that super gets treated like we treat eval today and won't work if it's been aliased. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calvin Spealman Sent: Sunday, April 29, 2007 12:31 PM To: Collin Winter Cc: Python Mailing List Subject: Re: [Python-Dev] New Super PEP On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: What if the instance isn't called self? PEP 3099 states that self will not become implicit; it's talking about method signatures, but I think that dictum applies equally well in this case. I don't use the name self. I use whatever the first argument name is, found by this line of python code: instance_name = calling_frame.f_code.co_varnames[0] So I can't use super with anything but the method's invocant? That seems arbitrary. This will be added to the open issues, but it comes back to the problem with allow the exact same super implementation both operate in the super(Class, Object).foo() form and also the super.__call__() form in the new version. Any suggestions are welcome for how to solve this. Also, it's my understanding that not all Python implementations have an easy analogue to CPython's frames; have you given any thought to whether and how PyPy, IronPython, Jython, etc, will implement this? I'll bring this up for input from PyPy and IronPython people, but I don't know any Jython people. Are we yet letting the alternative implementations influence so strongly what we do in CPython? I'm not saying screw them, just pointing out that there is always a way to implement anything, and if its some trouble for them, well, 2.6 or 3.0 targetting is far down the road for any of them yet. It's a smell test: if a given proposal is unduly difficult for anything but CPython to implement, it's probably a bad idea. The language shouldn't go down the Perl 5 road, where python (the C interpreter) becomes the only thing that can implement Python (the language). Understandable. I still haven't contacted anyone about it on in the PyPy or IronPython worlds, and anyone familiar with Jython who can comment would be appreciated. Ditto for PyPy and IronPython, even though I should be able to find some information there myself. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/dinov%40microsoft.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 29/04/2007 17.04, Guido van Rossum wrote: This is only a halfway fix to DRY, and it really only fixes the less important half. The important problem with super is that it encourages people to write incorrect code by requiring that you explicitly specify an argument list. Since calling super with any arguments other than the exact same arguments you have received is nearly always wrong, requiring that the arglist be specified is an attractive nuisance. Nearly always wrong? You must be kidding. There are tons of reasons to call your super method with modified arguments. E.g. clipping, transforming, ... Really? http://fuhm.net/super-harmful/ I don't believe that there are really so many. I would object to forcing super to *only* be able to pass unmodified arguments. But if it had an alternative syntax to do it (ala Dylan's next-method), I would surely use it often enough to make it worth. -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Giovanni Bajo [EMAIL PROTECTED] wrote: On 29/04/2007 17.04, Guido van Rossum wrote: Nearly always wrong? You must be kidding. There are tons of reasons to call your super method with modified arguments. E.g. clipping, transforming, ... Really? http://fuhm.net/super-harmful/ Hmmm. I've just counted more than 1600 usages of `super` in my sandbox. And all my tests pass. How does that square with the title of the rant you quote: Python's Super is nifty, but you can't use it ? Although the rest of `super-harmful` is slightly better than the title, the premise of James Knight is utterly wrong: Note that the __init__ method is not special -- the same thing happens with any method -- Christian Tanzerhttp://www.c-tanzer.at/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 02/05/2007 12.00, Christian Tanzer wrote: Nearly always wrong? You must be kidding. There are tons of reasons to call your super method with modified arguments. E.g. clipping, transforming, ... Really? http://fuhm.net/super-harmful/ Hmmm. I've just counted more than 1600 usages of `super` in my sandbox. And all my tests pass. And you don't follow any of the guidelines reported in that article? And you never met any of those problems? I find it hard to believe. The fact that your code *works* is of little importance, since the article is more about maintenance of existing code using super (and the suggestions he proposes are specifically for making code using super less fragile to refactorings). -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Please stop arguing about an opinionated piece of anti-super PR. On 5/2/07, Giovanni Bajo [EMAIL PROTECTED] wrote: On 02/05/2007 12.00, Christian Tanzer wrote: Nearly always wrong? You must be kidding. There are tons of reasons to call your super method with modified arguments. E.g. clipping, transforming, ... Really? http://fuhm.net/super-harmful/ Hmmm. I've just counted more than 1600 usages of `super` in my sandbox. And all my tests pass. And you don't follow any of the guidelines reported in that article? And you never met any of those problems? I find it hard to believe. The fact that your code *works* is of little importance, since the article is more about maintenance of existing code using super (and the suggestions he proposes are specifically for making code using super less fragile to refactorings). -- Giovanni Bajo ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: Draft Attempt Number Duo: PEP: XXX Title: New Super Checked in as PEP 3133. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Georg Brandl has just checked this PEP in as 367. I had submitted it to the [EMAIL PROTECTED] address, per the policy documentation. Sorry if I subverted some policy order, or was non-vocal about it. I didn't realize anyone else would check it in. On 5/1/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: Draft Attempt Number Duo: PEP: XXX Title: New Super Checked in as PEP 3133. -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Totally my screwup. I'll discard 3133. On 5/1/07, Calvin Spealman [EMAIL PROTECTED] wrote: Georg Brandl has just checked this PEP in as 367. I had submitted it to the [EMAIL PROTECTED] address, per the policy documentation. Sorry if I subverted some policy order, or was non-vocal about it. I didn't realize anyone else would check it in. On 5/1/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: Draft Attempt Number Duo: PEP: XXX Title: New Super Checked in as PEP 3133. -- --Guido van Rossum (home page: http://www.python.org/~guido/) -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
James I did not intend to imply that it should be impossible to pass James different arguments, only that passing the same ones should be James foolproof and not require repeating yourself. Then some other argument syntax than () is needed which clearly means, pass no arguments. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/30/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: James I did not intend to imply that it should be impossible to pass James different arguments, only that passing the same ones should be James foolproof and not require repeating yourself. Then some other argument syntax than () is needed which clearly means, pass no arguments. I second, because I would like an actually good way to do this. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Hi Calvin, On Mon, Apr 30, 2007 at 08:34:56AM -0400, Calvin Spealman wrote: If you want, you can also grab the reference implementation from my blog: http://ironfroggy-code.blogspot.com/ This reference implementation is broken. It doesn't pass the following test, for example: class A(object): __metaclass__ = autosuper def f(self): if type(self) is B: return we've got a B else: return oups class B(A): def f(self): return Super.f() assert B().f() == we've got a B I don't honestly think that you can easily fix the implementation to pass this test, but I'm ready to check proposed fixes and write tests for them. If there is really no working implementation yet then it shouldn't have been a PEP posted on python-dev in the first place, IMHO (and the discussion shouldn't go on on python-dev either). A bientot, Armin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/30/07, Armin Rigo [EMAIL PROTECTED] wrote: Hi Calvin, On Mon, Apr 30, 2007 at 08:34:56AM -0400, Calvin Spealman wrote: If you want, you can also grab the reference implementation from my blog: http://ironfroggy-code.blogspot.com/ This reference implementation is broken. It doesn't pass the following test, for example: class A(object): __metaclass__ = autosuper def f(self): if type(self) is B: return we've got a B else: return oups class B(A): def f(self): return Super.f() assert B().f() == we've got a B I don't honestly think that you can easily fix the implementation to pass this test, but I'm ready to check proposed fixes and write tests for them. If there is really no working implementation yet then it shouldn't have been a PEP posted on python-dev in the first place, IMHO (and the discussion shouldn't go on on python-dev either). You are absolutely correct, it should not have gone to python-dev. It was supposed to go to python-3000, where the initial discussion took place, where Guido asked for someone to write the PEP right off the bat. However, as much as I love GMail, it makes it less than easy to always know which mailing list I'm on, so I actually thought I was in that discussion at dev, not 3000. I apologize to everyone for mixing the threads between lists! This is exactly why I need to start pulling in all the dev lists to the summaries. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Calvin Spealman wrote: Comments welcome, of course. Bare with my first attempt at crafting a PEP. See below for comments; In general, I'm having problems understanding some of the terms used. I don't have any comments on the technical merits of the PEP yet, since I don't completely understand what is being said. PEP: XXX Title: Super As A Keyword Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30-Apr-2007 Python-Version: 2.6 Post-History: Abstract The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification = Replacing the old usage of super, calls to the next class in the MRO (method resolution order) will be made without an explicit super object creation, by simply accessing an attribute on the super type directly, which will automatically apply the class and instance to perform the proper lookup. The following example demonstrates the use of this. I don't understand the phrase 'by simply accessing an attribute on the super type directly'. See below for for more detail. :: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' The example is clear enough. The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit invokation of a super object upon a class and instance. When you say 'the super type' I'm not sure what you mean. Do you mean the next class in the MRO, or the base class in which the super method is defined? Or something else? What defines the 'proper' class? Can we have a definition of what a super object is? The enhancements to the super type will define a new __getattr__ classmethod of the super type, which must look backwards to the previous frame and locate the instance object. This can be naively determined by located the local named by the first argument to the function. Using super outside of a function where this is a valid lookup for the instance can be considered undocumented in its behavior. As I am reading this I get the impression that the phrase 'the super type' is actually referring to the 'super' keyword itself - for example, you say that the super type has a new __getattr__ classmethod, which I read as saying that you can now say super.x. Every class will gain a new special attribute, __super__, which is a super object instansiated only with the class it is an attribute of. In this capacity, the new super also acts as its own descriptor, create an instance- specific super upon lookup. I'm trying to parse that first sentence. How about Every class will gain a new special attribute, __super__, which refers to an instance of the associated super object for that class. What does the phrase 'the new super' refer to - they keyword 'super', the super type, or the super object? Much of this was discussed in the thread of the python-dev list, Fixing super anyone? [1]_. Open Issues --- __call__ methods Backward compatability of the super type API raises some issues. Names, the lookup of the __call__ of the super type itself, which means a conflict with doing an actual super lookup of the __call__ attribute. Namely, the following is ambiguous in the current proposal: :: super.__call__(arg) Which means the backward compatible API, which involves instansiating the super type, will either not be possible, because it will actually do a super lookup on the __call__ attribute, or there will be no way to perform a super lookup on the __call__ attribute. Both seem unacceptable, so any suggestions are welcome. super type's new getattr To give the behavior needed, the super type either needs a way to do dynamic lookup of attributes on the super type object itself or define a
Re: [Python-Dev] New Super PEP
On 29/04/07, James Y Knight [EMAIL PROTECTED] wrote: On Apr 28, 2007, at 10:43 PM, Calvin Spealman wrote: Abstract The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. This is only a halfway fix to DRY, and it really only fixes the less important half. The important problem with super is that it encourages people to write incorrect code by requiring that you explicitly specify an argument list. Since calling super with any arguments other than the exact same arguments you have received is nearly always wrong, Erm. Excuse me, but are you saying this code is wrong? class Rectangle: def __init__(self, width, height): self.width = width self.height = height class Square: def __init__(self, side): Rectangle.__init__(self, side, side) Or are you even saying this type of code is rare? I would disagree with both statements, therefore I also disagree with your recommendation. -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic. -- Frank Herbert ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
2007/4/29, Gustavo Carneiro [EMAIL PROTECTED]: On 29/04/07, James Y Knight [EMAIL PROTECTED] wrote: Since calling super with any arguments other than the exact same arguments you have received is nearly always wrong, Erm. Excuse me, but are you saying this code is wrong? class Rectangle: def __init__(self, width, height): self.width = width self.height = height class Square: def __init__(self, side): Rectangle.__init__(self, side, side) You probably mean class Square(Rectangle):. Anyway it's not wrong, but it isn't multiple-inheritance-friendly either. -- Lino Mastrodomenico E-mail: [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
James This is only a halfway fix to DRY, and it really only fixes the James less important half. The important problem with super is that it James encourages people to write incorrect code by requiring that you James explicitly specify an argument list. Since calling super with any James arguments other than the exact same arguments you have received James is nearly always wrong, requiring that the arglist be specified James is an attractive nuisance. Since the language doesn't require that a subclassed method take the same parameters as the base class method, you can't assume that it does. super() should simply mean call with no arguments. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Since calling super with any arguments other than the exact same arguments you have received is nearly always wrong, Erm. Excuse me, but are you saying this code is wrong? class Rectangle: def __init__(self, width, height): self.width = width self.height = height class Square: def __init__(self, side): Rectangle.__init__(self, side, side) That's not what he said. Your code does not call super(), so the observation that it normally should pass the exact same arguments does not apply. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Yes, I bad wordly things did. Fix will I. On 4/29/07, Talin [EMAIL PROTECTED] wrote: Calvin Spealman wrote: Comments welcome, of course. Bare with my first attempt at crafting a PEP. See below for comments; In general, I'm having problems understanding some of the terms used. I don't have any comments on the technical merits of the PEP yet, since I don't completely understand what is being said. PEP: XXX Title: Super As A Keyword Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30-Apr-2007 Python-Version: 2.6 Post-History: Abstract The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification = Replacing the old usage of super, calls to the next class in the MRO (method resolution order) will be made without an explicit super object creation, by simply accessing an attribute on the super type directly, which will automatically apply the class and instance to perform the proper lookup. The following example demonstrates the use of this. I don't understand the phrase 'by simply accessing an attribute on the super type directly'. See below for for more detail. :: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' The example is clear enough. The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit invokation of a super object upon a class and instance. When you say 'the super type' I'm not sure what you mean. Do you mean the next class in the MRO, or the base class in which the super method is defined? Or something else? What defines the 'proper' class? There is some ambiguous nature there that I missed. I think I used the same term for both the super type, as in the actual builtin type named super and to refer to the next type in the MRO order after the current type. What proper terminology would differentiate? Can we have a definition of what a super object is? An instance of the builtin type named super. Something for which isinstance(o, super) is True. The enhancements to the super type will define a new __getattr__ classmethod of the super type, which must look backwards to the previous frame and locate the instance object. This can be naively determined by located the local named by the first argument to the function. Using super outside of a function where this is a valid lookup for the instance can be considered undocumented in its behavior. As I am reading this I get the impression that the phrase 'the super type' is actually referring to the 'super' keyword itself - for example, you say that the super type has a new __getattr__ classmethod, which I read as saying that you can now say super.x. Yes. Every class will gain a new special attribute, __super__, which is a super object instansiated only with the class it is an attribute of. In this capacity, the new super also acts as its own descriptor, create an instance- specific super upon lookup. I'm trying to parse that first sentence. How about Every class will gain a new special attribute, __super__, which refers to an instance of the associated super object for that class. Check. What does the phrase 'the new super' refer to - they keyword 'super', the super type, or the super object? the new super refers to the updated super type this PEP proposes. Instances of the new super type will act as their own descriptors, which is how they are bound to specific instances of the classes they are associated with. Much of this was discussed in the thread of the python-dev list, Fixing super anyone? [1]_. Open Issues --- __call__ methods Backward compatability of the super type API raises some
Re: [Python-Dev] New Super PEP
On 4/28/07, James Y Knight [EMAIL PROTECTED] wrote: This is only a halfway fix to DRY, and it really only fixes the less important half. The important problem with super is that it encourages people to write incorrect code by requiring that you explicitly specify an argument list. Since calling super with any arguments other than the exact same arguments you have received is nearly always wrong, requiring that the arglist be specified is an attractive nuisance. Nearly always wrong? You must be kidding. There are tons of reasons to call your super method with modified arguments. E.g. clipping, transforming, ... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/28/07, Calvin Spealman [EMAIL PROTECTED] wrote: [snip] The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) [snip] The enhancements to the super type will define a new __getattr__ classmethod of the super type, which must look backwards to the previous frame and locate the instance object. This can be naively determined by located the local named by the first argument to the function. Using super outside of a function where this is a valid lookup for the instance can be considered undocumented in its behavior. What if the instance isn't called self? PEP 3099 states that self will not become implicit; it's talking about method signatures, but I think that dictum applies equally well in this case. Also, it's my understanding that not all Python implementations have an easy analogue to CPython's frames; have you given any thought to whether and how PyPy, IronPython, Jython, etc, will implement this? Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: What if the instance isn't called self? PEP 3099 states that self will not become implicit; it's talking about method signatures, but I think that dictum applies equally well in this case. I don't use the name self. I use whatever the first argument name is, found by this line of python code: instance_name = calling_frame.f_code.co_varnames[0] Also, it's my understanding that not all Python implementations have an easy analogue to CPython's frames; have you given any thought to whether and how PyPy, IronPython, Jython, etc, will implement this? I'll bring this up for input from PyPy and IronPython people, but I don't know any Jython people. Are we yet letting the alternative implementations influence so strongly what we do in CPython? I'm not saying screw them, just pointing out that there is always a way to implement anything, and if its some trouble for them, well, 2.6 or 3.0 targetting is far down the road for any of them yet. I'll add a reference implementation I have to the second draft of the PEP. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Draft Attempt Number Duo: PEP: XXX Title: New Super Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Apr-2007 Python-Version: 2.6 Post-History: 28-Apr-2007, 29-Apr-2007 Abstract The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification = Within the specification section, some special terminology will be used to distinguish similar and closely related concepts. Super type will refer to the actual builtin type named super. Next Class/Type in the MRO will refer to the class where attribute lookups will be performed by super, for example, in the following, A is the Next class in the MRO for the use of super. :: class A(object): def f(self): return 'A' class B(A): def f(self): super(B, self).f() # Here, A would be out Next class in the # MRO, of course. A super object is simply an instance of the super type, which is associated with a class and possibly with an instance of that class. Finally, new super refers to the new super type, which will replace the original. Replacing the old usage of super, calls to the next class in the MRO (method resolution order) will be made without an explicit super object creation, by simply accessing an attribute on the super type directly, which will automatically apply the class and instance to perform the proper lookup. The following example demonstrates the use of this. :: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit invokation of a super object upon a class and instance. The enhancements to the super type will define a new __getattr__ classmethod of the super type, which must look backwards to the previous frame and locate the instance object. This can be naively determined by located the local named by the first argument to the function. Using super outside of a function where this is a valid lookup for the instance can be considered undocumented in its behavior. This special method will actually be invoked on attribute lookups to the super type itself, as opposed to super objects, as the current implementation works. This may pose open issues, which are detailed below. Every class will gain a new special attribute, __super__, which refers to an instance of the associated super object for that class In this capacity, the new super also acts as its own descriptor, create an instance-specific super upon lookup. Much of this was discussed in the thread of the python-dev list, Fixing super anyone? [1]_. Open Issues --- __call__ methods Backward compatability of the super type API raises some issues. Names, the lookup of the __call__ of the super type itself, which means a conflict with doing an actual super lookup of the __call__ attribute. Namely, the following is ambiguous in the current proposal: :: super.__call__(arg) Which means the backward compatible API, which involves instansiating the super type, will either not be possible, because it will actually do a super lookup on the __call__ attribute, or there will be no way to perform a super lookup on the __call__ attribute. Both seem unacceptable, so any suggestions are welcome. Actually keeping the old super around in 2.x and creating a completely new super type seperately may be the best option. A future import or even a simple import in 2.x of the new super type from some builtin module may offer a way to choose which each module uses, even mixing uses by binding to different names. Such a builtin module might be called 'newsuper'. This module is also the reference implementation, which I will present below. super type's new getattr To give the
Re: [Python-Dev] New Super PEP
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: Draft Attempt Number Duo: PEP: XXX Title: New Super Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Apr-2007 Python-Version: 2.6 Post-History: 28-Apr-2007, 29-Apr-2007 Abstract The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification = Within the specification section, some special terminology will be used to distinguish similar and closely related concepts. Super type will refer to the actual builtin type named super. Next Class/Type in the MRO will refer to the class where attribute lookups will be performed by super, for example, in the following, A is the Next class in the MRO for the use of super. :: class A(object): def f(self): return 'A' class B(A): def f(self): super(B, self).f() # Here, A would be out Next class in the # MRO, of course. A super object is simply an instance of the super type, which is associated with a class and possibly with an instance of that class. Finally, new super refers to the new super type, which will replace the original. Replacing the old usage of super, calls to the next class in the MRO (method resolution order) will be made without an explicit super object creation, by simply accessing an attribute on the super type directly, which will automatically apply the class and instance to perform the proper lookup. The following example demonstrates the use of this. :: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit invokation of a super object upon a class and instance. The enhancements to the super type will define a new __getattr__ classmethod of the super type, which must look backwards to the previous frame and locate the instance object. This can be naively determined by located the local named by the first argument to the function. Using super outside of a function where this is a valid lookup for the instance can be considered undocumented in its behavior. This special method will actually be invoked on attribute lookups to the super type itself, as opposed to super objects, as the current implementation works. This may pose open issues, which are detailed below. Every class will gain a new special attribute, __super__, which refers to an instance of the associated super object for that class In this capacity, the new super also acts as its own descriptor, create an instance-specific super upon lookup. Much of this was discussed in the thread of the python-dev list, Fixing super anyone? [1]_. Open Issues --- __call__ methods Backward compatability of the super type API raises some issues. Names, the lookup of the __call__ of the super type itself, which means a conflict with doing an actual super lookup of the __call__ attribute. Namely, the following is ambiguous in the current proposal: :: super.__call__(arg) Which means the backward compatible API, which involves instansiating the super type, will either not be possible, because it will actually do a super lookup on the __call__ attribute, or there will be no way to perform a super lookup on the __call__ attribute. Both seem unacceptable, so any suggestions are welcome. Actually keeping the old super around in 2.x and creating a completely new super type seperately may be the best option. A future import or even a simple import in 2.x of the new super type from some builtin module may offer a way to choose which each module uses, even mixing uses by binding to different names. Such a builtin module might be
Re: [Python-Dev] New Super PEP
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: [snip] I still wasn't really aware of any alternative suggestions that need to be included in this. Here are two off the top of my head: http://mail.python.org/pipermail/python-3000/2007-April/006805.html http://mail.python.org/pipermail/python-3000/2007-April/006811.html More generally, you're ignoring all the proposals along the line of let's fix the super type without making it a keyword. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: [snip] I still wasn't really aware of any alternative suggestions that need to be included in this. Here are two off the top of my head: http://mail.python.org/pipermail/python-3000/2007-April/006805.html http://mail.python.org/pipermail/python-3000/2007-April/006811.html More generally, you're ignoring all the proposals along the line of let's fix the super type without making it a keyword. Collin Winter I'll add both of these, but neither had much support in the original thread. Also, I don't see that I'm ignoring anything along the line of let's fix the super type without making it a keyword, because I am not advocating it become an actual keyword. I was always under the impression that was never meant literally. We have no where else where a keyword looks like an object. At the absolutely most I could almost see how super may become a constant, a'la None, in 3.0, but never a keyword. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: [snip] I still wasn't really aware of any alternative suggestions that need to be included in this. Here are two off the top of my head: http://mail.python.org/pipermail/python-3000/2007-April/006805.html http://mail.python.org/pipermail/python-3000/2007-April/006811.html More generally, you're ignoring all the proposals along the line of let's fix the super type without making it a keyword. Collin Winter I'll add both of these, but neither had much support in the original thread. Also, I don't see that I'm ignoring anything along the line of let's fix the super type without making it a keyword, because I am not advocating it become an actual keyword. Sorry, I was thrown off by the original title of your PEP. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Now that I think about it, your proposal seems to address only one of super()'s three forms (http://docs.python.org/lib/built-in-funcs.html#l2h-72): 1. super(type) 2. super(type, instance) 3. super(type, type) If your intention is to remove the first and third forms from the language, please justify their removal in your PEP, including your proposed work-around for their use-cases. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Hi Calvin, On Sat, Apr 28, 2007 at 10:43:04PM -0400, Calvin Spealman wrote: The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Can you describe how you intend the dynamic attribute lookup to find the proper class? Is it related to your proposal to add a new attribute '__super__' to each class? If so, I don't see how... and if not, can you explain why you need '__super__' then? A bientot, Armin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/29/07, Armin Rigo [EMAIL PROTECTED] wrote: Hi Calvin, On Sat, Apr 28, 2007 at 10:43:04PM -0400, Calvin Spealman wrote: The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Can you describe how you intend the dynamic attribute lookup to find the proper class? Is it related to your proposal to add a new attribute '__super__' to each class? If so, I don't see how... and if not, can you explain why you need '__super__' then? Yes, it is highly dependent on the new __super__ attribute. See the reference implementation for the how. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: What if the instance isn't called self? PEP 3099 states that self will not become implicit; it's talking about method signatures, but I think that dictum applies equally well in this case. I don't use the name self. I use whatever the first argument name is, found by this line of python code: instance_name = calling_frame.f_code.co_varnames[0] So I can't use super with anything but the method's invocant? That seems arbitrary. Also, it's my understanding that not all Python implementations have an easy analogue to CPython's frames; have you given any thought to whether and how PyPy, IronPython, Jython, etc, will implement this? I'll bring this up for input from PyPy and IronPython people, but I don't know any Jython people. Are we yet letting the alternative implementations influence so strongly what we do in CPython? I'm not saying screw them, just pointing out that there is always a way to implement anything, and if its some trouble for them, well, 2.6 or 3.0 targetting is far down the road for any of them yet. It's a smell test: if a given proposal is unduly difficult for anything but CPython to implement, it's probably a bad idea. The language shouldn't go down the Perl 5 road, where python (the C interpreter) becomes the only thing that can implement Python (the language). Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Now that I think about it, your proposal seems to address only one of super()'s three forms (http://docs.python.org/lib/built-in-funcs.html#l2h-72): 1. super(type) 2. super(type, instance) 3. super(type, type) If your intention is to remove the first and third forms from the language, please justify their removal in your PEP, including your proposed work-around for their use-cases. The first is not removed, but actually utilized by the proposal itself. That is what the __super__ attributes are: super objects associated only with a type, but no instance. As for the third form, I wasn't even aware of it, I thought. I didn't consider the cases like how super is used in __new__ methods, but I tested it with the reference implementation, and it works just fine. If there are any cases I'm missing, there is no reason not to support it. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: On 4/29/07, Calvin Spealman [EMAIL PROTECTED] wrote: On 4/29/07, Collin Winter [EMAIL PROTECTED] wrote: What if the instance isn't called self? PEP 3099 states that self will not become implicit; it's talking about method signatures, but I think that dictum applies equally well in this case. I don't use the name self. I use whatever the first argument name is, found by this line of python code: instance_name = calling_frame.f_code.co_varnames[0] So I can't use super with anything but the method's invocant? That seems arbitrary. This will be added to the open issues, but it comes back to the problem with allow the exact same super implementation both operate in the super(Class, Object).foo() form and also the super.__call__() form in the new version. Any suggestions are welcome for how to solve this. Also, it's my understanding that not all Python implementations have an easy analogue to CPython's frames; have you given any thought to whether and how PyPy, IronPython, Jython, etc, will implement this? I'll bring this up for input from PyPy and IronPython people, but I don't know any Jython people. Are we yet letting the alternative implementations influence so strongly what we do in CPython? I'm not saying screw them, just pointing out that there is always a way to implement anything, and if its some trouble for them, well, 2.6 or 3.0 targetting is far down the road for any of them yet. It's a smell test: if a given proposal is unduly difficult for anything but CPython to implement, it's probably a bad idea. The language shouldn't go down the Perl 5 road, where python (the C interpreter) becomes the only thing that can implement Python (the language). Understandable. I still haven't contacted anyone about it on in the PyPy or IronPython worlds, and anyone familiar with Jython who can comment would be appreciated. Ditto for PyPy and IronPython, even though I should be able to find some information there myself. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
At 01:19 PM 4/29/2007 -0400, Calvin Spealman wrote: Backward compatability of the super type API raises some issues. Names, the lookup of the __call__ of the super type itself, which means a conflict with doing an actual super lookup of the __call__ attribute. Namely, the following is ambiguous in the current proposal: :: super.__call__(arg) Which means the backward compatible API, which involves instansiating the super type, will either not be possible, because it will actually do a super lookup on the __call__ attribute, or there will be no way to perform a super lookup on the __call__ attribute. Both seem unacceptable, so any suggestions are welcome. Note that if you have a class with a __call__ method, it will still be called, even if you override __getattribute__ to return something else when asked for the __call__ attribute, e.g.: class DoubleCall(object): ... def __call__(self): ... return called! ... def __getattribute__(self, attr): ... if attr=='__call__': ... return lambda: attribute dc = DoubleCall() dc() 'called!' dc.__call__() 'attribute' ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New Super PEP
Phillip J. Eby wrote: a __call__ method, it will still be called, even if you override __getattribute__ to return something else dc = DoubleCall() dc() 'called!' dc.__call__() 'attribute' That is sufficiently fragile that I would be uncomfortable with a feature that couldn't be supplied otherwise. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Hi Calvin, On Sun, Apr 29, 2007 at 02:53:58PM -0400, Calvin Spealman wrote: Yes, it is highly dependent on the new __super__ attribute. See the reference implementation for the how. Ah, there is a reference implementation. There is no link to it in the PEP you posted, hence my confusion. Where is it? A bientot, Armin. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New Super PEP - draft 2
(Adding python-3000 to the Cc, since that is where much of the recent discussion occurred) Calvin's full proposal is archived at: http://mail.python.org/pipermail/python-dev/2007-April/072835.html Abstract The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) The alternatives section needs to explain why super.foo(*args) is the right level of simplification. Alternatives include (1)No changes Con: fragility in name binding (2)super(__this_class__, self).foo(*args) Con: The (__this_class__, self) is boilerplate. Note that the __this_class__ PEP should be referenced, if only as a possible explanation for what is happening under the covers. (3)self.__super__.foo(*args) # or super.foo(*args) Con: Shouldn't need a __double_underscore_name__ in normal functions. Con: __super__ (even if renamed super) is not a simple attribute; it is a property representing a partially applied function (that gets further applied by the self) (4) super(self, *args)# ? or __super__(self, *args) Actually, I sort of like this one, as it allows the upcall signature to exactly match the method definition signature. Con: super is still not a simple attribute. Con: changing the method name becomes a hassle. (5) super.foo(self, *args)# ? or __super__.foo(self, *args) Con: self isn't really an argument just to super.foo -- it is an argument to super which is used to find/instantiate foo in the first place. (Plus the objections to partially applied function attributes.) (6) super # ? or super() Pro: matches java; doesn't require a repeat of *args Con: doesn't match anything else in python, needs to be a keyword (and would still need object support). In the first example: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' You should probably include tests that fail with some of the more obvious (but wrong) solutions, such as class A(object): def f(self): return 'A' class Bempty(A): # Make sure it doesn't call the A or B method twice pass class B(Bempty): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' class E(C, B):# Show that B can point to C as next or vice versa def f(self): return 'E' + super.f() assert E().f() == 'ECBA' class F(D):# show that the instance may not be a direct instance pass assert D().f() == 'DBCA' The enhancements to the super type will define a new __getattr__ classmethod of the super type, Did you really mean, it gets the class of builtin.super, but no info on which class is using super? If not, it isn't a classmethod of the super type. It may be a classmethod of the currently-being-defined-type (__this_class__). which must look backwards to the previous frame and locate the instance object. frame manipulation is fragile. Even if it didn't cause problems for other implementations, it causes problems for nested functions and callbacks. def f(self, button, *args): def callback(*args): super(__this_class__, self).f(*args) button.callback=callback When this gets called, the appropriate self won't be in the frame, except as a lexically scoped variable (which might have a different name). Also, note that this fails on most of Thomas Wouters' advanced usages. While you say that super shouldn't be called outside a method, you can't really keep the super object itself from getting returned. Every class will gain a new special attribute, __super__, which refers to an instance of the associated super object for that class In this capacity, the new super also acts as its own descriptor, create an instance-specific super upon lookup. If you didn't say instance-specific, this would be equivalent to a class decorator, translating class A(object): ... into class A(object): ... A.__super__=super(A) As is, it gets a bit trickier, since you need to I think the translation is closer to class A(object):... @property def __super__(self): return __this_class__.__supermaker() A.__supermaker=super(A) I don't see a good
Re: [Python-Dev] New Super PEP
Gustavo Carneiro wrote: Erm. Excuse me, but are you saying this code is wrong? class Rectangle: def __init__(self, width, height): self.width = width self.height = height class Square: def __init__(self, side): Rectangle.__init__(self, side, side) The PEP is all about cooperative super calls, so it doesn't apply to this. I'd still rather see syntactic support for ordinary inherited calls before cooperative ones, as cooperative ones are used much more rarely, in my experience. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
[EMAIL PROTECTED] wrote: Since the language doesn't require that a subclassed method take the same parameters as the base class method, you can't assume that it does. The argument is that in the special case of a cooperative super call, it doesn't make sense for the parameter list to be different, because you don't know which method you're calling, so the signature of all methods along the super chain has to be standardised. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
Guido van Rossum wrote: Nearly always wrong? You must be kidding. There are tons of reasons to call your super method with modified arguments. E.g. clipping, transforming, ... That's a good point. Just because the *signature* is the same doesn't mean the *values* of the parameters need to be the same. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On Apr 29, 2007, at 9:07 PM, Greg Ewing wrote: Guido van Rossum wrote: Nearly always wrong? You must be kidding. There are tons of reasons to call your super method with modified arguments. E.g. clipping, transforming, ... That's a good point. Just because the *signature* is the same doesn't mean the *values* of the parameters need to be the same. This is quite true, and is indeed one case where it can be right to pass different arguments. Just in case there was confusion, I did not intend to imply that it should be impossible to pass different arguments, only that passing the same ones should be foolproof and not require repeating yourself. James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New Super PEP
Comments welcome, of course. Bare with my first attempt at crafting a PEP. PEP: XXX Title: Super As A Keyword Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30-Apr-2007 Python-Version: 2.6 Post-History: Abstract The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. Specification = Replacing the old usage of super, calls to the next class in the MRO (method resolution order) will be made without an explicit super object creation, by simply accessing an attribute on the super type directly, which will automatically apply the class and instance to perform the proper lookup. The following example demonstrates the use of this. :: class A(object): def f(self): return 'A' class B(A): def f(self): return 'B' + super.f() class C(A): def f(self): return 'C' + super.f() class D(B, C): def f(self): return 'D' + super.f() assert D().f() == 'DBCA' The proposal adds a dynamic attribute lookup to the super type, which will automatically determine the proper class and instance parameters. Each super attribute lookup identifies these parameters and performs the super lookup on the instance, as the current super implementation does with the explicit invokation of a super object upon a class and instance. The enhancements to the super type will define a new __getattr__ classmethod of the super type, which must look backwards to the previous frame and locate the instance object. This can be naively determined by located the local named by the first argument to the function. Using super outside of a function where this is a valid lookup for the instance can be considered undocumented in its behavior. Every class will gain a new special attribute, __super__, which is a super object instansiated only with the class it is an attribute of. In this capacity, the new super also acts as its own descriptor, create an instance- specific super upon lookup. Much of this was discussed in the thread of the python-dev list, Fixing super anyone? [1]_. Open Issues --- __call__ methods Backward compatability of the super type API raises some issues. Names, the lookup of the __call__ of the super type itself, which means a conflict with doing an actual super lookup of the __call__ attribute. Namely, the following is ambiguous in the current proposal: :: super.__call__(arg) Which means the backward compatible API, which involves instansiating the super type, will either not be possible, because it will actually do a super lookup on the __call__ attribute, or there will be no way to perform a super lookup on the __call__ attribute. Both seem unacceptable, so any suggestions are welcome. super type's new getattr To give the behavior needed, the super type either needs a way to do dynamic lookup of attributes on the super type object itself or define a metaclass for the builtin type. This author is unsure which, if either, is possible with C- defined types. When should we create __super__ attributes? ''' They either need to be created on class creation or on __super__ attribute lookup. For the second, they could be cached, of course, which seems like it may be the best idea, if implicit creation of a super object for every class is considered too much overhead. References == .. [1] Fixing super anyone? (http://mail.python.org/pipermail/python-3000/2007-April/006667.html) Copyright = This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://ironfroggy-code.blogspot.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/28/07, Calvin Spealman [EMAIL PROTECTED] wrote: Comments welcome, of course. Bare with my first attempt at crafting a PEP. PEP: XXX Title: Super As A Keyword Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30-Apr-2007 Python-Version: 2.6 Post-History: You need a section on alternate proposals. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On 4/28/07, Calvin Spealman [EMAIL PROTECTED] wrote: Comments welcome, of course. Bare with my first attempt at crafting a PEP. PEP: XXX Title: Super As A Keyword Version: $Revision$ Last-Modified: $Date$ Author: Calvin Spealman [EMAIL PROTECTED] Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 30-Apr-2007 Python-Version: 2.6 [snip] Which means the backward compatible API, which involves instansiating the super type, will either not be possible, because it will actually do a super lookup on the __call__ attribute, or there will be no way to perform a super lookup on the __call__ attribute. Both seem unacceptable, so any suggestions are welcome. You're offering absolutely zero backwards compatibility and you're targeting 2.6? Um, no; absolutely not. Even if you intend this for 3.0, you'll still need to define either a backwards compatibility solution or a migration strategy (e.g., a 2to3 fixer). Without a clear-cut way of addressing existing code, this idea is toast. Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New Super PEP
On Apr 28, 2007, at 10:43 PM, Calvin Spealman wrote: Abstract The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was called on. The premise of the new super usage suggested is as follows: super.foo(1, 2) to replace the old: super(Foo, self).foo(1, 2) Rationale = The current usage of super requires an explicit passing of both the class and instance it must operate from, requiring a breaking of the DRY (Don't Repeat Yourself) rule. This hinders any change in class name, and is often considered a wart by many. This is only a halfway fix to DRY, and it really only fixes the less important half. The important problem with super is that it encourages people to write incorrect code by requiring that you explicitly specify an argument list. Since calling super with any arguments other than the exact same arguments you have received is nearly always wrong, requiring that the arglist be specified is an attractive nuisance. Now, I'm no syntax designer, but, just being able to say super() seems nice to me. (but don't get too hung up on that spelling, the concept of not having to repeat the arglist is the important point.) James ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
