ught in one of the enclosing
frames).
This reminds me of something I've thought a few times - maybe the tuple
returned from sys.exc_info() should be a named tuple.
Tim Delaney
___
Python-3000 mailing list
Python-3000@python.org
http://mail.py
nd makes sure the '__class__' is
> available in any frame where 'super' is used.
>
> Code is welcome to also use __class__ directly. It is set to the class
> before decoration (since this is the only way that I can figure out
> how to generate the code).
>
>
ld be a syntax error (super as a keyword is only
> allowed as an atom). You could get the same effect with
>
> A().func(1, 2, **{'super': object()})
>
> but that's so obscure I don't mind.
I'd prefer to eliminate it, but that's a detail that can be taken
sed. Did we get a decision on
whether im_class should return the decorated or undecorated class, or did
you want me to leave that as an open issue?
I'm starting to feel somewhat embarrassed that I haven't had the time
available to work solidly on this, but don't let that stop you
cycle. Bound methods
don't come into it - it's the unbound method that's the problem.
> Since class and type are synonym (as you say) having both im_class and
> im_type would be a bad idea.
I'm struggling to think of another, not too complicated name that conveys
the sa
ant this attribute to represent - the
class/type that this method was defined in.
im_class would have also been suitable, but has had another, different
meaning since 2.2.
3. im_super - property that returns the unbound super object (for an unbound
method) and bound super object (for a bound met
which you
> seem to be proposing here.
Think I must have been explaining poorly - if you look at the reference
implementation in the PEP, you'll see that that's exactly what's held in the
'super' free variable.
I think your proposal is basically what I wa
Bah - this should have gone to Pyton-3000 too, since it's discussing the
PEP.
Tim Delaney
Tim Delaney wrote:
> Guido van Rossum wrote:
>
>> - This seems to be written from the POV of introducing it in 2.6.
>> Perhaps the PEP could be slightly simpler if it could focus jus
Nick Coghlan wrote:
> Tim Delaney wrote:
>> So the question is, should the method store the class, or the name?
>> Looking up by name could pick up a totally unrelated class, but
>> storing the undecorated class could miss something important in the
>> decoration.
Tim Delaney wrote:
> Phillip J. Eby wrote:
>> At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>>> Determining the class object to use
>>> '''''''''''''''''''''&#x
Phillip J. Eby wrote:
> At 05:23 PM 5/14/2007 +1000, Tim Delaney wrote:
>> Determining the class object to use
>> '''''''''''''''''''''''''''
Here is my modified version of PEP 367. The reference implementation in it
is pretty long, and should probably be split out to somewhere else (esp.
since it can't fully implement the semantics).
Cheers,
Tim Delaney
PEP: 367
Title: New Super
Version: $Revision$
Last-Modified: $Date$
A
the 'super' PEP to not rely on this in any way, but will add a
note that your PEP (and other changes) may make the implementation simpler,
and so the implementation should be revisited before 3.0.
The semantics of 'super' OTOH should be fully clarified in our PEP.
Tim Del
From: "Collin Winter" <[EMAIL PROTECTED]>
> On 4/30/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
>> Would you prefer me to work with Calvin to get his existing PEP to match
>> my
>> proposal, or would you prefer a competing PEP?
>
> Please work to
sends my
name out as - Delaney, Timothy.
I'm not going to be able to submit a spearate PEP for my proposal before COB
April 30th (it's already the 1st over here ...) and I have to head to work.
Would you prefer me to work with Calvin to get his existing PEP to match my
proposal, or woul
rrently, it can mean
whatever you want it to.
class A(object):
@staticmethod
def f():
print super(A)
print super(A, A)
Cheers,
Tim Delaney
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
f, *p, **kw):
return super(*p, **kw)
So, I guess my question is whether the most common case of calling the base
class method with the same name is worth having some further syntactic sugar
to avoid repetition? I think it is, but that would be your call Guido.
Cheers,
Tim Delaney
er = super' line above would normally throw an UnboundLocalError,
but the bytecode hacking I've done causes it to work.
Comments before I start writing up the PEP? Or if anyone has a PEP partially
written, do you want to incorporate any of the above into it?
Tim Delaney
autosuper.
rint 'A:', super
class B(A):
def f(self):
def inner():
print 'B:', super
super.f()
inner()
Should the call to inner() result in a call to A.f? Currently my bytecode
version doesn't do this. I think this
From: "Tim Delaney" <[EMAIL PROTECTED]>
> I've been off sick from work for over a week - I've been following this
> discussion, but now I think I've got something which matches all the
> criteria we've been discussing, so I've changed my subscri
super()
it would be functionally identical to the following:
class B(A):
def f(self):
super.f()
This could be easily implemented by having the 'super' constructor take a
'name' parameter (which would be passed the name of current method in the
setup
there wouldn't be any.
But the idea of a property returning an object as complex as a view still
feels wrong to me.
Tim Delaney
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
ht
y/except/else/finally clause i.e.
try:
pass
except AttributeError as e1:
pass
except NameError as e2:
pass
is equivalent to:
try:
try:
pass
except AttributeError, e1:
pass
except NameError,
23 matches
Mail list logo
