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
