A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2005-January/050630.html below:

[Python-Dev] Let's get rid of unbound methods

[Python-Dev] Let's get rid of unbound methods [Python-Dev] Let's get rid of unbound methodsPhillip J. Eby pje at telecommunity.com
Tue Jan 4 19:48:24 CET 2005
At 10:28 AM 1/4/05 -0800, Guido van Rossum wrote:

>Of course, more changes would be needed: docs, the test suite, and
>some simplifications to the instance method object implementation in
>classobject.c.
>
>Does anyone think this is a bad idea?

Code that currently does 'aClass.aMethod.im_func' in order to access the 
function object would break, as would code that inspects 'im_self' to 
determine whether a method is a class or instance method.  (Although code 
of the latter sort would already break with static methods, I suppose.)

Cursory skimming of the first 100 Google hits for 'im_func' seems to show 
at least half a dozen instances of the first type of code, though.  Such 
code would also be in the difficult position of having to do things two 
ways in order to be both forward and backward compatible.

Also, I seem to recall once having relied on the behavior of a 
dynamically-created unbound method (via new.instancemethod) in order to 
create a descriptor of some sort.  But I don't remember where or when I did 
it or whether I still care.  :)

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4