[Discuss] Guido van Rossum steps down

[kentborg at borg.org (Kent Borg)]

On 07/17/2018 03:23 PM, Mike Small wrote:
>> In hindsight, they made a mistake to break compatibility in 3.0, yet
> Is this bothering people very much? My impression was that the
> adjustments tend to be minimal and that there are tools to
> help.

If one is writing a conventional program the main differences seem to be 
minor:

 ?- Strings are no longer sequences of bytes, they are sequences of 
variable-length characters. I am all in favor of diacriticals and 
supporting languages other than English, and UTF-8 is a wonderful hack, 
but it is a hack, and to embed that hack in heart of computer languages 
seems wrong. I don't know what the better alternative is for encoding 
human language strings, but I deal with a lot of strings that are not 
human language, they are sequences of 8-bit bytes. Python isn't the only 
language that does this, and again, I don't know that it be wrong, but 
it is a difference.

 ?- A lot of things that used to return something that looked like a 
sequence of static data now return an iterator into some other data 
structure. This more compact than, say, copying thousands of keys from a 
key/value dictionary, but God save you if the dictionary you are 
iterating over changes while you are looking at it. (In 2.x this is a 
problem, too, but in a more predicable way.) Again, I don't know that 
this be wrong, but it is a difference.

> People now expect good multithreading in scripting languages?

Python is a now more a "language" than a "scripting language". Computers 
are fast, we like wasting them, so the costs are not bad for light work. 
For heavy work Python is also great--providing the actual heavy lifting 
is done in libraries written in, say, C.

Back to 3.0 being incompatible: Making a programmer be careful about 
iterators and change strings--and a few (good) syntax changes--wasn't 
the expensive part. They broke binary compatibility for what it means to 
be a .so library that Python can call. Long ago I was enthusiastic about 
switching to Python 3! Until I discovered all the libraries I was using 
were 2.x only. Now libraries are catching up and some are saying they 
will kill 2.x support in a year or two.

Making multithreading fast on Python would require breaking libraries 
again. I don't think they will get away with that. Instead Python 3 
seems to have settled for more of a cooperative multitasking mode of 
yielding to other python threads pretty much explicitly. In a world 
where the thing in your pocket has many CPUs, Python is stuck with only 
being able to use one.

I exaggerate: I have written a program that was a single Python process, 
running multiple Python threads, yet it could saturate multiple 
processors. The secret is my threads were not doing much in Python, so 
it didn't matter that Python is terrible at switching between threads, 
what mattered was that the libraries I was calling left the Python 
environment and GIL behind so they could be scheduled across multiple CPUs.

> I always assumed Rust was sort of the next D

As I complain that Python is behind in multithreading, let me also say 
that languages that are no so far behind...are still behind. I think 
multithreading should be done in a way similar to how Rust does it, 
where the threading isn't the hard part, it is data safety in the face 
of multiple threads that is the hard part. Python didn't manage to do 
any innovation in data ownership, either.

> It's staticly typed and relatively verbose, right? 

Not quite. Functions need to be declared with data types--though the 
type might be somewhat generic--but variables can leave the type off if 
the type can be inferred from the context (it usually can).? And the 
declaration of a variable can also be your first use of it. Echoes of BASIC:

 ? let foo = some_func(42);

> Big change from Python.

Not as big as you might guess. In that regard.

Bigger change is that Rust is harder. It requires the program be 
explicit about things that other languages ignore. Ignoring is easier.

Python being easy to learn does have negatives. Nearly anyone can write 
a program in Python. But
not everyone should be writing computer programs.

I think one of the problems with "kids these days" is they don't spend 
much time thinking about what their program should do nor how it should 
do it, instead they quickly start programming. The rise of Python makes 
that worse.

> Well, let me know when it really is on the downward trajectory, so I can
> finally get around to properly learning it. Work is sometimes easier to
> find when you claim to know languages that were once very popular but
> have since been damned with the "legacy" label.

It might be going "downhill" in some regards now, but not in popularity. 
Hold off of you want legacy.

-kb