[ python-Bugs-743267 ] super passes bad arguments to __get__ when used w/class

[SourceForge.net]

Bugs item #743267, was opened at 2003-05-25 19:00
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Phillip J. Eby (pje)
Summary: super passes bad arguments to __get__ when used w/class

Initial Comment:
Run the following code to demonstrate the issue:

====
class Getter(object):
    def __get__(self, ob, typ=None):
        print "called with", (ob, typ)

class Base(object):
    foo = Getter()

class Subclass(Base):
    pass

print
print

Base().foo
Subclass().foo
super(Subclass,Subclass()).foo

Base.foo
Subclass.foo
super(Subclass,Subclass).foo
====

Notice that super(Subclass,Subclass).foo is calling the
descriptor with the *class* object, not 'None' as is
done for the analagous cases that don't use super().

The only reason this ever "works" is because
'classmethod' ignores the 'ob' parameter to '__get__'.
 However, this breaks when using 'super' to access
property descriptors in 2.3, and it will also break any
user-defined descriptors that are accessed via super().

The behavior is the same in 2.2, and is arguably broken
there as well.  For example,
'super(someclass,someclass).X' (where 'X' is a normal
instance method) results in X being a *bound* method,
bound to the class, rather than an *unbound* method,
ready for use with an explicit instance.

Personally, I would be happy if super() grew an extra
argument to disambiguate whether you are doing a
(class,instance) or (class,class) call, anyway.  When
using super() with metaclasses, I've encountered
situations where super() guessed wrong, because I was
using a type that was both an instance of, and a
subclass of, the same type.  Being able to explicitly
request that this "class method" form of super is being
used, would eliminate this confusion as well.  In the
face of ambiguity... ;)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-03-29 12:23

Message:
Logged In: YES 
user_id=6656

Phillip, it's a bit less of an issue as you've already backported this, 
but it helps if you mention the fixing revisions of the various files 
in the bug report.  Conversely, you should mention the bug # in 
the checkin message, but you did that already :-)

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-03-25 02:49

Message:
Logged In: YES 
user_id=56214

Committed and backported.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 22:54

Message:
Logged In: YES 
user_id=6380

Phillip, now that you have CVS perms, please check this in
yourself (and backport).

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-03-06 12:35

Message:
Logged In: YES 
user_id=56214

Here's a patch against the CVS head to add a test for the
problem, and fix it.  Please backport to the 2.3 branch as
well.  Thanks!

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-25 19:09

Message:
Logged In: YES 
user_id=6656

I don't think you'll find any difference between the trunk
and release23-maint in this area, so it doesn't make much
difference.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 19:06

Message:
Logged In: YES 
user_id=56214

super().descriptor example:

class Base(object):
    aProp = property(lambda self: "foo")

class Sub(Base):
    def test(klass):
        print super(Sub,klass).aProp
    test = classmethod(test)

Sub.test()

This prints "foo", when it should print "<property object at
0x4024f84c>" instead.

To be precise, the issue is that accessing any descriptor
that behaves differently when retrieved on the class vs. the
instance, will behave incorrectly when accessed via super()
from a classmethod in a subclass.  Classmethods themselves
work correctly because they behave the same way no matter
how you retrieve them.

At present I think the patch should simply change the
descr_get call in super_getattro so that it checks whether
su->obj==su->obj_type, and if so, pass in NULL instead of
su->obj as the second argument to descr_get.

Should I create this patch against the 2.3 maintenance
branch, or against the head?  I'd like to make sure it gets
into the next 2.3.x bugfix release.  (I didn't realize this
bug was still open until I stumbled across it the other day,
and I'm not expecting to upgrade to 2.3 production use for a
few months yet.  I've been using a pure-Python
reimplementation of super() as a workaround.)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-25 15:57

Message:
Logged In: YES 
user_id=6380

> However, this breaks when using &#039;super&#039; to access
> property descriptors in 2.3, and it will also break any
> user-defined descriptors that are accessed via super().

Can you give an example of this use case?

I don't have a strong opinion on this; methinks you should
go ahead and prepa patch...

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 07:06

Message:
Logged In: YES 
user_id=56214

Assigning to Guido to request pronouncement on the correct
way to fix this before I attempt to create patch(es).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470