[Guido]
> > Apart from the tests that were testing the behavior of im_class, I
> > found only a single piece of code in the standard library that used
> > im_class of an unbound method object (the clever test in the pyclbr
> > test). Uses of im_self and im_func were more widespread. Given the
> > level of cleverness in the pyclbr test (and the fact that I wrote it
> > myself) I'm not worried about widespread use of im_class on unbound
> > methods.
[Marc-Andre]
> I guess this depends on how you define widespread use. I'm using
> this feature a lot via the basemethod() function in mxTools for
> calling the base method of an overridden method in mixin classes
> (basemethod() predates super() and unlike the latter works for
> old-style classes).
I'm not sure I understand how basemethod is supposed to work; I can't
find docs for it using Google (only three hits for the query mxTools
basemethod). How does it depend on im_class?
> What I don't understand in your reasoning is that you are talking
> about making an unbound method look more like a function.
That's a strange interpretation. I'm getting rid of the unbound method
object altogether.
> Unbound
> methods and bound methods are objects of the same type -
> the method object.
Yeah I know that. :-)
And it is one of the problems -- the two uses are quite distinct and
yet it's the same object, which is confusing.
> By turning an unbound method into a function
> type, you break code that tests for MethodType in Python
> or does a PyMethod_Check() at C level.
My expectation is that there is very little code like that. Almost
all the code that I found doing that in the core Python code (none in
C BTW) was in the test suite.
> If you want to make methods look more like functions,
> the method object should become a subclass of the function
> object (function + added im_* attributes).
Can't do that, since the (un)bound method object supports binding
other callables besides functions.
[Glyph]
> On the other hand, if PJE's "monkey typing" PEP is accepted, there will
> probably be lots more reasons to serialize unbound methods, for
> descriptive purposes.
Let's cross that bridge when we get to it.
> It's not the strongest use-case in the world, but is the impetus to
> remove unbound method objects from Python that much stronger?
Perhaps not, but we have to strive for simplicity whenever we can, to
counteract the inevitable growth in complexity of the language
elsewhere.
> I like
> the fact that it's simpler, but it's a small amount of extra simplicity,
> it doesn't seem to enable any new use-cases,
I think it does. You will be able to get a method out of a class and
put it into another unrelated class. Previously, you would have to use
__dict__ or im_func to do that.
Also, I've always liked the explanation of method calls that
C().f()
is the same as
C.f(C())
and to illustrate this it would be nice to say "look, C.f is just a function".
> and it breaks the potential for serialization.
For which you seem to have no use yourself. The fact that you support
it doesn't prove that it's used -- large software packages tend to
accrete lots of unused features over time, because it's safer to keep
it in than to remove it.
This is a trend I'd like to buck with Python. There's lots of dead
code in Python's own standard library, and one day it will bite the
dust.
[Barry]
> I have no personal use cases, but it does make me vaguely uncomfortable
> to lose im_class. Isn't it possible to preserve this attribute?
That vague uncomfort is called FUD until proven otherwise. :-)
Keeping im_class would be tricky -- the information isn't easily
available when the function is defined, and adding it would require
changing unrelated code that the patch so far didn't have to get near.
Also, it would not be compatible -- the unbound method sets im_class
to whichever class was used to retrieve the attribute, not the class
in which the function was defined.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
