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

[Steven D'Aprano]

On 07/04/13 10:09, Mark Janssen wrote:
>>> 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?),

More like Python 0.1, or at least 0.9 which is the oldest version I have.
Data values have always been implemented as objects in Python, even in the
early days before the class/type integration.


> we had to
> gain an obscure system of __new__ in addition to __init__, and the
> nice clean conceptual model got obfuscated.

On the contrary, the "everything is an object" system is nice and clean.
Having some values be objects and some values not be means that you have
two distinct models, boxed and unboxed values, like in Java.


> (Why do some objects need it and others don't?)

Why do some objects need __len__ and some objects don't? It depends on the
object and what it is supposed to do.

__new__ is the constructor that actually builds the object. __init__ is the
initializer. Yes, we could drop the initializer, and only have a constructor.
But because the constructor does more, it is trickier to use, especially for
beginners. E.g. there is no self, because the instance doesn't exist yet!
That makes it harder to use correctly. Dropping __init__ and keeping only
__new__ will make the language worse.

On the other hand, we cannot drop __new__, and just keep __init__. That's
what the old-style "classic classes" did, and not having __new__ is a major
pain. 90% of the time you don't need __new__ and __init__ will do the job,
but when you need it, you really need it, and __init__ is no substitute.

So having both __new__ and __init__ available is a big Win for useability.


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


Do you realise that those longs that you call "fine" are precisely the
same as the ints you're complaining about?



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

Let's not.




-- 
Steven