Python was designed (was Re: Multi-threading in Python vs Java)

[Chris Angelico]

On Tue, Oct 15, 2013 at 6:18 AM, John Nagle <nagle at animats.com> wrote:
> On 10/12/2013 3:37 PM, Chris Angelico wrote:
>> "Designed".
>>
>> You simply can't get a good clean design if you just let it grow by
>> itself, one feature at a time.
>
>     No, Python went through the usual design screwups.  Look at how
> painful the slow transition to Unicode was, from just "str" to
> Unicode strings, ASCII strings, byte strings, byte arrays,
> 16 and 31 bit character builds, and finally automatic switching
> between rune widths. Old-style classes vs. new-style classes.  Adding a
> boolean type as an afterthought (that was avoidable; C went through
> that painful transition before Python was created).    Operator "+"
> as concatenation for built-in arrays but addition for NumPy
> arrays.
>
>     Each of those reflects a design error in the type system which
> had to be corrected.

Oh, Python's design wasn't perfect - that's a pretty much impossible
goal anyway. Sometimes you don't learn what you ought to have done
till it's been in production for a while - that's why, for instance,
these happened:

https://wiki.theory.org/YourLanguageSucks#Fixed_in_Python_3

You'd have to be completely omniscient to avoid that kind of
misjudgment, and breaking backward compatibility is such a major cost
that sometimes design errors just have to be kept. But you'll still
end up with something far cleaner than would come from ad-hoc
undirected changes; it'll be a design with warts, rather than a lack
of design.

>     The type system is now in good shape. The next step is to
> make Python fast.  Python objects have dynamic operations suited
> to a naive interpreter like CPython.  These make many compile
> time optimizations hard. At any time, any thread can monkey-patch
> any code, object, or variable in any other thread.  The ability
> for anything to use "setattr()" on anything carries a high
> performance price.  That's part of why Unladen Swallow failed
> and why PyPy development is so slow.

Yeah, this does make things hard. But that dynamism is a fundamental
part of Python's design, even if it's used by almost nothing. I'd say
this isn't proof of a design error, just a consequence of a design
decision. Python isn't for everyone, nor for every task - sometimes
it'll be too slow for what you want. So be it! There are plenty of
places where it's good. And there are similar languages (hi Pike!) for
when you want a bit more performance.

ChrisA