[Python-ideas] Reviving PEP 3140 - "str(container) should call str(item), not repr(item)"

[Andrew Barnert]

From: Mark Janssen <dreamingforward at gmail.com>
>Sent: Saturday, April 6, 2013 5:09 PM
>
>
>>>> This is a problem with "everything is an object" model:  no
>>>> recognition is made between a distinction that is very high up the
>>>> "object taxonomy":  container vs. atomic elements.
>>>
>>> Python does not have non-object atomic data elements.
>
>> Yeah.  I think this is where we made a mistake -- we went too far into
>> "purity" and away from Tim's Zen wisdom of "practicality".  We don't
>> need ints as objects.  Once Python did this (Python 2.6?), we had to
>> gain an obscure system of __new__ in addition to __init__, and the
>> nice clean conceptual model got obfuscated.  (Why do some objects need
>> it and others don't?)  The only nice thing about it is big-nums and
>> the complete abstraction that python provides of it, but I believe,
>> now, that it's a premature optimization.
>>
>> The only reason we do it is to make the very nice illusion of
>> arbitrarily large arithmetic.  But in practice, this is only used to
>> impress others, not for much real programming.  Frankly, I have to
>> admit that longs did just fine, with their automatic conversion from
>> ints when things got too big.
>
>
>Before the int/long unification, Python had two different integral types, which were both objects. The int object used a C long for internal storage, but it was an immutable, garbage-collected, object, with methods, represented in CPython as a PyObject* with the appropriate slots and so on and so on.
>
>
>The only practical cost of that merger was a very minor performance cost. (And one that's unlikely to matter in any real program—if you need to do lots of arithmetic very quickly, Python ints were far too slow without numpy or similar; for anything else, longs were more than fast enough.)
>
>
>> Let's update the OOP paradigm and accept we can't *totally* get away
>
>> from the machine and differentiate between atomic types like integers
>> and let containers be the "first" Object.
>
>
>
>How would that even help solve the problem? You'd still need to be able to make the exact same container-vs.-non-container distinction for all of the non-numeric objects that can go into containers. And whatever solution you come up with for those objects will work just as well for numbers as objects. So, adding non-object numbers just means you have to solve two problems instead of one. (Actually, three, because now you either need to design explicit boxing, or come up with a way to let containers, and variables for that matter, hold both objects and non-objects.)
>
>
>To put it another way, if containers are the "first" object, then what are dates, quaternions, slices, files, functions, GUI windows, client connections, context managers, exceptions, regexes, zlib compression states, threads, processes, …? And even if you _could_ implement all of those as non-object atomic types, what about user-defined application objects like cars, cats, and employees?
>
>
>There are only four answers to this problem: (1) nothing is an object (Haskell, Scheme); (2) everything is an object (Python, Ruby); (3) only some things are objects, and only objects can go into containers (Java); (4) only some things are objects, and there are completely different kinds of containers for objects and non-objects (ObjC). It's hard to see how either (3) or (4) is simpler than (2), or more practical (other than for low-level performance).