[Python-Dev] how to test behavior wrt an extension type?

[Alex Martelli]

On 2005 Jan 16, at 11:17, Raymond Hettinger wrote:

> [Alex]
>> So, as per discussion here, I have prepared a patch (to the
> maintenance
>> branch of 2.3, to start with) which adds unit tests to highlight these
>> issues, and fixes them in copy.py.  This patch should go in the
>> maintenance of 2.3 and 2.4, but in 2.5 a different approach based on
>> new special descriptors for special methods is envisaged (though
>> keeping compatibility with classic extension types may also require
>> some patching to copy.py along the lines of my patch).
>
> For Py2.5, do you have in mind changing something other than copy.py?
> If so, please outline your plan.  I hope your not planning on wrapping
> all special method access as descriptor look-ups -- that would be a
> somewhat radical change.

The overall plan does appear to be exactly the "somewhat radical 
change" which you hope is not being proposed, except it's not my plan 
-- it's Guido's.  Quoting his first relevant post on the subject:
'''
	From: 	  gvanrossum at gmail.com
	Subject: 	Re: getting special from type, not instance (was Re: 
[Python-Dev] copy confusion)
	Date: 	2005 January 12 18:59:13 CET
       ...
I wonder if the following solution wouldn't be more useful (since less
code will have to be changed).

The descriptor for __getattr__ and other special attributes could
claim to be a "data descriptor" which means that it gets first pick
*even if there's also a matching entry in the instance __dict__*.
Quick illustrative example:

>>> class C(object):
      foo = property(lambda self: 42)   # a property is always a "data
descriptor"

>>> a = C()
>>> a.foo
42
>>> a.__dict__["foo"] = "hello"
>>> a.foo
42
>>>

Normal methods are not data descriptors, so they can be overridden by
something in __dict__; but it makes some sense that for methods
implementing special operations like __getitem__ or __copy__, where
the instance __dict__ is already skipped when the operation is invoked
using its special syntax, it should also be skipped by explicit
attribute access (whether getattr(x, "__getitem__") or x.__getitem__
-- these are entirely equivalent).

We would need to introduce a new decorator so that classes overriding
these methods can also make those methods "data descriptors", and so
that users can define their own methods with this special behavior
(this would be needed for __copy__, probably).

I don't think this will cause any backwards compatibility problems --
since putting a __getitem__ in an instance __dict__ doesn't override
the x[y] syntax, it's unlikely that anybody would be using this.
"Ordinary" methods will still be overridable.

PS. The term "data descriptor" now feels odd, perhaps we can say "hard
descriptors" instead. Hard descriptors have a __set__ method in
addition to a __get__ method (though the __set__ method may always
raise an exception, to implement a read-only attribute).
'''

All following discussion was, I believe, in the same thread, mostly 
among Guido, Phillip and Armin.  I'm focusing on getting copy.py fixed 
in 2.3 and 2.4, w/o any plan yet to implement Guido's idea.  If you 
dislike Guido's idea (which Phillip, Armin and I all liked, in 
different degrees), it might be best for you to read that other thread 
and explain the issues there, I think.


Alex