[py-dev] Re: [Python-Dev] Getting rid of unbound methods: patch available

holger krekel hpk at trillke.net
Mon Jan 17 12:56:52 CET 2005


Hi Armin, 

On Mon, Jan 17, 2005 at 11:27 +0000, Armin Rigo wrote:
> On Sun, Jan 16, 2005 at 10:12:37PM -0800, Guido van Rossum wrote:
> > https://sourceforge.net/tracker/index.php?func=detail&aid=1103689&group_id=5470&atid=305470
> > 
> > Here's a patch that gets rid of unbound methods, as
> > discussed here before. A function's __get__ method
> > now returns the function unchanged when called without
> > an instance, instead of returning an unbound method object.
> 
> This patch breaks py.test quite extensively, which is no surprise because it
> contains a number of tests along the lines of hasattr(func, 'im_self').  

pydoc and other inspection-related modules and packages will likely 
break as well.  Especially adding im_self/im_func to plain functions
breaks assumptions that have been valid with Python for many years. 

> After a quick scan over py.test I'm not sure how easily this could be fixed,
> and more importantly how easily it would be to fix it while still preserving
> compatibility with existing Python versions.

I guess we would need to keep track of class information ourselves. So
a test item would need to grow a class-attribute so that we know which 
class a function belongs to.  Maybe it's more difficult then that. 

> I would suggest that we (I) give the issue some serious thoughts, and if it
> really makes the life of the py lib difficult, it will be a good "real life"
> example of breakage.  I'm sure it would be a good argument to postpone the
> patch to the faraway ages usually called "Python 3000".

Yes, i agree.  I am pretty sure that py.test isn't the only
real-life example that breaks by changing the introspection
model for functions/methods.  The gain is too small to warrant
such a change before Python 3000 IMHO. After all, where is the
"real need" to introduce the change?  (this question is often 
thrown at change-ideas by Guido :-) 

    holger



More information about the Pytest-dev mailing list