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

[Mark Janssen]

On Mon, Oct 14, 2013 at 12:18 PM, John Nagle <nagle at animats.com> wrote:
> On 10/12/2013 3:37 PM, Chris Angelico wrote:
>> On Sat, Oct 12, 2013 at 7:10 AM, Peter Cacioppi
>> <peter.cacioppi at gmail.com> wrote:
>>> Along with "batteries included" and "we're all adults", I think
>>> Python needs a pithy phrase summarizing how well thought out it is.
>>> That is to say, the major design decisions were all carefully
>>> considered, and as a result things that might appear to be
>>> problematic are actually not barriers in practice. My suggestion
>>> for this phrase is "Guido was here".
>>
>> "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.

I hesitate to poke my nose in here, but Python is fine.  No one knows
how to design the perfect language from the start, otherwise it would
be here.   But Python has set the precedent for allowing
backwards-incompatibility to fix language problems and that's what
will keep it from breaking.

> Look at how
> painful the slow transition to Unicode was, from just "str" to
> Unicode strings, ASCII strings, byte strings, byte arrays,

This is where I wish I could have been involved with the discussion,
but I was outside of civilization at the time, and was not able to
contribute.

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

All of this will get fixed, but the problem is that you are stirring
up issues without really understanding the problem.   The problem is
something that is at the bleeding-edge of Computer Science itself and
settling on a theory of types.  I've answered this by creating a
unified object model, but no one has understood why the hell anyone
needs one, so I'm sitting around waiting for a friend..

>     Each of those reflects a design error in the type system which
> had to be corrected.

To call it a "design error" makes it seem like someone make a decision
that resulted in a mistake, but it isn't (wasn't) that simple.

>     The type system is now in good shape. The next step is to
> make Python fast.

Woah, boy.  There's no reason to make an incomplete design faster, for
psuedo-problems that no one will care about in 5-10 years.  The field
has yet to realize that it needs an object model, or even what that
is.

> Python objects have dynamic operations suited
> to a naive interpreter like CPython.

Naive, no.

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

Yes, and all of that is because, the world has not settled on some
simple facts.  It needs an understanding of type system.  It's been
throwing terms around, some of which are well-defined, but others,
not:  there has been enormous cross-breeding that has made mutts out
of everybody and someone's going to have to eat a floppy disk for
feigning authority where there wasn't any.

Mark J
Tacoma, Washington