[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