What is not objects in Python?

[Terry Reedy]

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