[Python-Dev] New Super PEP

[Dino Viehland]

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: 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