George Sakkis wrote:
Sure, "len" looks better than lambda x:x.__len__(), but the same would
be true if there was an "upper" builtin for the following example:
s = ['a', 'd', 'B', 'C']
s2 = [u'a', u'd', u'B', u'C']
upper = lambda x: x.upper()
sorted(s, key=upper)
['a', 'B', 'C', 'd']
sorted(s2, key=upper)
[u'a', u'B', u'C', u'd']
No difference in principle, just len() happens to be implemented more
often than upper().
I disagree. One versus many classes is a principle. If a method is
used on objects of just one class, the class attribute can be used and
passed directly.
sorted(s, key = str.upper)
sorted(s2, key = unicode.upper)
The problem is having two text classes, which Guido considers to be a
mess and which Python did not have originally and which 3.0 also does
not have, even though bytes keeps the string methods. Mixing int, long,
and float numbers is or should be more common than mixing str and
unicode strings, and certainly more common than mixing str strings and
bytes in 3.0 (which is actively discouraged).
To me, discerning the implicit principles of Python's design makes it
easier to learn and remember, even if they are not as exact as one might
like. The choices are not random, and so one can do better than rote
memory.
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
