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. 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).

Regards,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---------------------------------------------------------------
            http://boredomandlaziness.skystorm.net
_______________________________________________
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

Reply via email to