Nick Coghlan wrote:
Guido van Rossum wrote:
What do people think? (My main motivation for this, as stated before,
is that it adds complexity without much benefit.)
I'm in favour, since it removes the "an unbound method is almost like a
bare function, only not quite as useful" distinction. It would allow
things like str.join(sep, seq) to work correctly for a Unicode
separator.
This won't work. Strings and Unicode are two different types,
not subclasses of one another.
It also allows 'borrowing' of method implementations without
inheritance.
>
I'm a little concerned about the modification to pyclbr_input.py, though
(since it presumably worked before the patch). Was the input file
tweaked before or after the test itself was fixed? (I'll probably get
around to trying out the patch myself, but that will be on Linux as
well, so I doubt my results will differ from yours).
The other question is the pickling example - an unbound method currently
stores meaningful data in im_class, whereas a standard function doesn't
have that association. Any code which makes use of im_class on unbound
methods (even without involving pickling)is going to have trouble with
the change. (Someone else will need to provide a real-life use case
though, since I certainly don't have one).
I don't think there's much to worry about. At the C level,
bound and unbound methods are the same type. The only
difference is that bound methods have the object
attribute im_self set to an instance object, while
unbound methods have it set NULL.
Given that the two are already the same type, I don't
really see much benefit from dropping the printing of
"unbound" in case im_self is NULL... perhaps I'm missing
something.
As for real life examples: basemethod() in mxTools uses
.im_class to figure the right base method to use (contrary
to super(), basemethod() also works for old-style classes).
basemethod() in return if used in quite a few applications
to deal with overriding methods in mixin classes.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 10 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
_______________________________________________
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
