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
