[Python-Dev] New Super PEP

[Michael Foord]

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: python-dev-bounces+dinov=microsoft.com at python.org [mailto:python-dev-bounces+dinov=microsoft.com at python.org] 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 <collinw at gmail.com> wrote:
>   
>> On 4/29/07, Calvin Spealman <ironfroggy at gmail.com> wrote:
>>     
>>> On 4/29/07, Collin Winter <collinw at gmail.com> 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 at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>
>