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

[Steven D'Aprano]

Are you suggesting that Guido van Rossum wasn't omniscient back in 1991
when he first released Python??? OH MY GOD!!! You ought to blog about
this, let the world know!!!!

You are making a strawman out of John's statements:

Python went through the usual design screwups. [screwup list which
perhaps pinche John most] Each of those reflects a design error in the
type system which had to be corrected.

The reasonable interpretation of John's statements is that propriety and
even truth is a function of time: It was inappropriate for GvR to have
put in unicode in 1990. It was appropriate in 2008. And it was done.
You may call that being-human-not-God. I call that being real.

And I agree with you! But that's not what John wrote. John called it a
design screw-up. His very first example was the slow transition to
Unicode. Not "here's a choice that made sense at the time", but "screw-
up".

 

[Mark Lawrence]

Much the same can be said for IPv6

My encyclopedia doesn't mention Python, unicode or IPv6. Not that it's
old, but the stone mason retired years ago

--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

 

[Antoon Pardon]

Op 15-10-13 01:11, Chris Angelico schreef:

... NumPy definitely isn't part of the language. It's not even part of
the standard library, it's fully third-party.

That doesn't matter. Adding and concating are different operations and
their are types in which both occur rather naturally. So as a designer
of such a class you have to choose for which operation you use the
natural python operator and for which operation you have to do it
differently. NumPy is just an example that you can't escape this sort
of incompatibilities in python.

 

[Steven D'Aprano]

By the time I started using Python, new-style classes existed and were
the recommended way to do things, so I never got the "feel" for
old-style classes. I assume there was a simplicity to them, since
new-style classes were described as having a performance cost, but one
worth paying. My guess is it comes under the category of "would have to
be omniscient to recognize what would happen"; Steven, maybe you can
fill us in?

Heh, I'm not privy to why GvR decided to have built-in types and classes
be distinct but it wasn't a performance issue. The very first
versions of Python didn't have user-defined types at all:

http://python-history.blogspot.com.au/2009/02/adding-support-for-user-
defined-classes.html

For a while classic classes were faster, but I don't think that's been
the case for a long while now.

You can read up more about the unification of types and classes here:

http://www.python.org/download/releases/2.2.3/descrintro/

and the associated PEPs:

http://www.python.org/dev/peps/pep-0252/
http://www.python.org/dev/peps/pep-0253/


but note that the PEPs may no longer reflect the current implementation.
The descrintro document above is interesting for its explanation of how
descriptors work.

I don't know about that. Some languages get by just fine without
dedicated a boolean type. Python didn't have them, then it had them as
integers, now it has them as bools.

Actually, Python's bools *are* ints


If you read the whole python-history blog on blogspot, you'll see that
Python's had it's share of mistakes, design failures and other "oops!"
moments. I think that it is a testament to GvR's over-all design that the
end result has been so good, despite the mistakes, as well as Python's
conservative-but-not-too-conservative approach to changes. Compared to
(say) Firefox, which comes out with new releases seemingly twice a week,
Python is slow to change and conservative; compared to (say) Fortran,
which changes in a time-span of decades rather than years, it's quite
fast moving. I think Python has more or less hit the sweet-spot.

 

[Antoon Pardon]

Op 15-10-13 10:57, Chris Angelico schreef:

So what should "abc" + "def" result in, if addition is different from
concatenation?

A type error.

No, adding strings should concatenate them. And other
arithmetic operators make sense, too; Python doesn't happen to
implement str-str or str/str, but some languages do:

(3) Result: "foo##bar##asdf##qwer"

PHP has separate addition and concatenation operators, and it doesn't
help anything (granted, the biggest problem is that every other
language we work with uses + to concat strings, so it's an easy source
of bugs); having multiple operators for "add the elements of these
arrays" and "add these arrays together" is really orthogonal to the
general issue of adding and concatenating needing different operators.

No it is not, because adding elements to an array is concatenation.
If you want the array adding operator to be the same as the adding
operator for other types and you want the array concatenating operator
be the same as the concatenating operator for other types, you can
only do that if the two operations use different operators.

Since python use the same, you are forced to introduce some kind
of incompatibility.

If you have a library function that assumes '+' for concatenating
sequences and you have a library function that assumes '+' has
group like properties you can't implement your arrays in a way
they can use both.

 

[Steven D'Aprano]

On Tue, Oct 15, 2013 at 6:48 PM, Antoon Pardon


So what should "abc" + "def" result in, if addition is different from
concatenation?

TypeError, like any other unsupported operator.

No, adding strings should concatenate them. And other
arithmetic operators make sense, too;

For some definition of "sense".

Python doesn't happen to implement str-str or str/str, but some
languages do:

Which languages are you talking about?

For the record, if PHP is one of them, I consider that a good sign that
it shouldn't be done

(1) Result: "def"

Eww. What would "xyz" - "abc" give? How about "cba" - "abc"?

And "abcdabc" - "abc"?

Justify your answers.

(3) Result: "foo##bar##asdf##qwer"

And what, pray tell, would "foo bar" / " " be on its own?

How about "foo bar" * "*"?

Seems to me that using s/t*u as a way to perform substring replacement is
too clever by half.

PHP has separate addition and concatenation operators, and it doesn't
help anything

That's because PHP is beyond help.

(granted, the biggest problem is that every other language
we work with uses + to concat strings, so it's an easy source of bugs);
having multiple operators for "add the elements of these arrays" and
"add these arrays together" is really orthogonal to the general issue of
adding and concatenating needing different operators.

Yes -- string concatenation and array operations are not really related,
although string concatenation is a special case of array concatenation.
But it is a wild over-generalisation to assume that because strings are
arrays, and (numeric) arrays might want separate element-wise
multiplication and whole-array multiplication operators, therefore
strings need to support the same too.

Personally, I think string and array concatenation ought to be & rather
than +. That would free up + for element-wise addition for arrays, while
still allowing & for concatenation. Of course, the cost would be the loss
of an element-wise bit-and operator. You win some, you lose some.

 

[rusi]

If you read the whole python-history blog on blogspot, you'll see that
Python's had it's share of mistakes, design failures and other "oops!"
moments. I think that it is a testament to GvR's over-all design that the
end result has been so good, despite the mistakes, as well as Python's
conservative-but-not-too-conservative approach to changes. Compared to
(say) Firefox, which comes out with new releases seemingly twice a week,
Python is slow to change and conservative; compared to (say) Fortran,
which changes in a time-span of decades rather than years, it's quite
fast moving. I think Python has more or less hit the sweet-spot.

Yes heartily agree.

Mostly we have systems/software/languages that fall into one of two categories:
a. Completely immobile -- which means the only change is the inevitable bitrot of slow aging
b. So much blood that we cant see the 'edge' in the bleeding edge

That way python is surely in a sweetspot (for me):

In 2001 I started teaching programming with a computer projector (rather than chalk). This meant that classes became more dynamic and alive but also my head was more than ever on the line -- with chalk-board you can occasionally fudge your way out with bullshit. When the projector is displaying anunexpected result or a backtrace/segfault there is no such room!!

By chance(?) it was also the time I started teaching python.

And for these last 10+ years python has been like a faithful servant -- useful, unobtrusive, predictable. The number of times Ive had to say in a class: "Ok guys I dont know..." (In short I am screwed) is hardly a handful.

One of the very occasional embarrassing exceptions:
https://mail.python.org/pipermail/python-list/2011-July/609362.html

 

[Chris Angelico]

Which languages are you talking about?

For the record, if PHP is one of them, I consider that a good sign that
it shouldn't be done

My examples here are from Pike.

Eww. What would "xyz" - "abc" give? How about "cba" - "abc"?

And "abcdabc" - "abc"?

Justify your answers.

"xyz" - "abc"; (1) Result: "xyz"
"cba" - "abc"; (2) Result: "cba"
"abcdabc" - "abc";

(3) Result: "d"

Every instance of the subtracted-out string is removed. It's something
like x.remove(y) in many other languages.

And what, pray tell, would "foo bar" / " " be on its own?

A two-element array "foo","bar":

"foo bar" / " ";

(4) Result: ({ /* 2 elements */
"foo",
"bar"
})

How about "foo bar" * "*"?

That's an error (the equivalent of TypeError).

Seems to me that using s/t*u as a way to perform substring replacement is
too clever by half.

Maybe It looks fancy for something like this. Normally, I use
string division with iteration, but there is a more direct "replace"
function for when that's being done.

Personally, I think string and array concatenation ought to be & rather
than +. That would free up + for element-wise addition for arrays, while
still allowing & for concatenation. Of course, the cost would be the loss
of an element-wise bit-and operator. You win some, you lose some.

I don't know who was first to implement string+string --> concat, but
since it's swept the world, it's worth keeping just on that basis, in
the same way that the use of octal for character escapes like "\123"
is worth keeping:
83

Confused me no end when I came across BIND's use of that syntax to
mean decimal. So if & has its problems and + has its problems, go with
+, as it'll confuse less people.

ChrisA

 

[wxjmfauth]

Le lundi 14 octobre 2013 21:18:59 UTC+2, John Nagle a écrit :

----

[...]

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

Yes, a real disaster.

This "poor" Python is spending its time in reencoding
when necessary, without counting the fact it's necessary to
check if reencoding is needed.

Where is Unicode? Away.

jmf

 

[Mark Janssen]

Objects in programming languages (or 'values' if one is more functional programming oriented) correspond to things in the world.

One of the things you're saying there is that "values correspond to
things in the world". But you will not get agreement in computer
science on that anymore than saying "numbers correspond to things in
the world" -- they are abstractions that are not supposed to
correspond to things. (Objects, OTOH, were intended to, so your
statement has mixed truthiness.)

Types on the other hand correspond to our classifications and so are things in our minds.

That is not how a C programmer views it. They have explicit
"typedef"s that make it a thing for the computer.

So for the world 'to settle' on a single universal type system is about as nonsensical and self contradictory as you and I having the same thoughts.

Yes, well clearly we are not "having the same thoughts", yet the
purpose of the academic establishment is to pin down such terminology
and not have these sloppy understandings everywhere. You dig?

To see how completely nonsensical a classification system of a so-called alien culture is, please read:
http://en.wikipedia.org/wiki/Celestial_Emporium_of_Benevolent_Knowledge

And then reflect that the passage is implying that CONVERSELY our natural/obvious/FACTual classifications would appear similarly nonsensical to them.

The same in the world of programming languages:

No. There is one world in which the computer is well-defined. All
others are suspect.

Here's an APL session
$ ./apl
a perfectly good (and for many of us old-timers a very beautiful) type system
but completely incompatible with anything designed in the last 40 years!

Yeah, well 40 years ago they didn't have parsers. The purpose of
having a field of computer science worthy of the name, is to advance
the science not let this riff-raff dominate the practice.

 

[Mark Lawrence]

Le lundi 14 octobre 2013 21:18:59 UTC+2, John Nagle a écrit :

----

[...]

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

Yes, a real disaster.

This "poor" Python is spending its time in reencoding
when necessary, without counting the fact it's necessary to
check if reencoding is needed.

Where is Unicode? Away.

jmf

I very much look forward to seeing your correct Python unicode
implementation on the bug tracker.

--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

 

[Tim Chase]

(3) Result: "d"

Every instance of the subtracted-out string is removed. It's
something like x.remove(y) in many other languages.

Or as one might write x.remove(y) in Python:

for demo in ("xyz", "cba", "abcdabc"):
print repr(demo), "->", repr(demo.replace("abc", ""))

A two-element array "foo","bar":

(4) Result: ({ /* 2 elements */
"foo",
"bar"
})

which in Python sounds suspiciously like dividend.split(divisor)

So Python's giving both functionalities in ways that are more
readable (and in the case of "-", more flexible, as you can replace
with anything, not just delete the matching content).

While subtraction and division of strings make theoretical sense, I'm
glad I don't have to think about them in my Python code ;-)

-tkc

 

[Grant Edwards]

Yeah, well 40 years ago they didn't have parsers.

That seems an odd thing to say. People were assembling and compiling
computer programs long before 1973.

How did they do that without parsers?

 

[Mark Lawrence]

Yeah, well 40 years ago they didn't have parsers.

I'm very pleased to see that (presumably) some Americans do have a sense
of humour.

--
Roses are red,
Violets are blue,
Most poems rhyme,
But this one doesn't.

Mark Lawrence

 

[Peter Cacioppi]

only I'm focusing on the importance of design rather than deifying

the person who designed it.

I'm cool with deification here. I'll happily get on my knees and bow towards Holland while chanting "Guido ... I'm not worthy" 5 times a day, if that's part of the cult.

Want an odd and ranty thread this one turned into. I think Python is awesome. For me, it literally inspires awe.

If you don't agree, and yet you're working in Python anyway, I kind of feel bad for you, just a little.

Cheers and thanks again.

 

[Piet van Oostrum]

Yeah, well 40 years ago they didn't have parsers. The purpose of
having a field of computer science worthy of the name, is to advance
the science not let this riff-raff dominate the practice.

Hah! 40 years ago I wrote a parser generator (similar to yacc, that I did not know) and used it to generate a parser for Algol 68.

 

[rusi]

One of the things you're saying there is that "values correspond to
things in the world". But you will not get agreement in computer
science on that anymore than saying "numbers correspond to things in
the world"

Ok… I better take back the '…or values' because that's a completely separate (at least separable) argument and one which I dont want to go into with you.

The original argument: There can be a type-system that everyone can 'settleupon.'

The new (and avoidable) one: Objects and values are equivalent/conflatable as alternate models for building systems -- and therefore OOP and FP.

The APL on the other (third?) hand is at one remove the type argument.
One remove because you are now to see it not from the vanilla programmer's perspective but from the the pov of the language implementer. Once you agree to that you would (hopefully!!) see some things:

When implementing a scanner/lexer characters are the indicators of the types we are interested in. In C, a '/' may be a divide indicator but also a comment-starter. Dozens of other such 'type-confusions' in most languages. APL bites the bullet, enriches the character set and therefore simplifies:
â starts a comment
÷ is divide
/ is the reduce (higher order) operator

Likewise
= is equal
↠is assignment
Whether in academics or in professional software engineering, if you had a clue of the man-hours and therefore money wasted in programmers/students writing '=' instead of '==' in C code, you would appreciate the sense in these decisions.

And you think that APL is behind rather than ahead of the competition?

Ah well… the mercilessness of the Dunning-Kruger effect…

 

[Mark Janssen]

That seems an odd thing to say. People were assembling and compiling
computer programs long before 1973.

I'm using the word "parser" in the sense of a stand-alone application
that became useful with the growing open source culture that was
developing in the 70's. Prior to that you have punch cards where
there's no meaningful definition of "parsing" because there are no
tokens. Would you say you were "parsing" on an old digital machine
where you input programs with binary switches?

But after the advent of the dumb terminal, parsers started evolving,
and that was the early 70's. I might be a year or two off, but I only
gave one significant digit there. ;^)

Cheers,

 

[Grant Edwards]

I'm using the word "parser" in the sense of a stand-alone application
that became useful with the growing open source culture that was
developing in the 70's. Prior to that you have punch cards where
there's no meaningful definition of "parsing" because there are no
tokens.

What do you mean "there are no tokens?". Pascal/Fortran/COBOL on
a deck of punched cards is parsed/compiled the same as it is in a file
on a hard drive.

Would you say you were "parsing" on an old digital machine
where you input programs with binary switches?

No, that's not what I'm talking about. I'm talking about compiling
Fortran or PL/1 or whatnot.

But after the advent of the dumb terminal, parsers started evolving,
and that was the early 70's. I might be a year or two off, but I only
gave one significant digit there. ;^)

I don't understand what dumb terminals have to do with it.

 

[Peter Cacioppi]

I don't know if I want to step into the flames here, but my understanding has always been that in the absence of polymorphism the best you can do is "object based" programming instead of "object oriented" programming.

Object based programming is a powerful step forward. The insight that by associating data structures and methods together you can significantly improve readability and robustness.

Object oriented programming takes things further, most significantly by introducing the idea that the object reference you are referencing might be a run time dependent sub-class. Even Python, which isn't strongly typed, manages polymorphism by allowing the self argument to a sub-class of the methodclass.

There are many wonderful examples of object based programming in C. I believe VB (not VB.net, the older VBA language) is object based but not object oriented.

True object oriented programming seems to require proper support from the language itself, because the run-time resolution of the "this/self" reference needs specific constructs in the language.

Bear in mind that my usual disclaimer when wading into the flames like thisis to quote Randy Newman ... "I may be wrong .... but I don't think so!!"