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.
My comment was based on misremembering how str.join actually works. It automatically flips to Unicode when it finds a Unicode string in the sequence - however, it doesn't do that for the separator, since that should already have been determined to be a string by the method lookup machinery.
However, looking at the code for string_join suggests another possible issue with removing unbound methods. The function doesn't check the type of the first argument - it just assumes it is a PyStringObject.
PyString_Join adds the typecheck that is normally performed by the method wrapper when str.join is invoked from Python.
The issue is that, if the unbound method wrapper is removed, str.join(some_unicode_str, seq) will lead to PyString_AS_STRING being invoked on a PyUnicode object. Ditto for getting the arguments out of order, as in str.join(seq, separator). At the moment, the unbound method wrapper takes care of raising a TypeError in both of these cases. Without it, we get an unsafe PyString macro being applied to an arbitrary type.
I wonder how many other C methods make the same assumption, and skip type checking on the 'self' argument? It certainly seems to be the standard approach in stringobject.c.
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
