Fedora ponders the Python 2 end game [LWN.net]

Fedora ponders the Python 2 end game

Posted Aug 1, 2017 23:52 UTC (Tue) by dgm (subscriber, #49227) [Link] (2 responses)

So, can we say it's time to Go, but not to Go 2? What would Dijkstra say about that?

Fedora ponders the Python 2 end game

Posted Aug 2, 2017 3:36 UTC (Wed) by tome (subscriber, #3171) [Link] (1 responses)

He'd say ouch but he'd be unharmed.

Fedora ponders the Python 2 end game

Posted Aug 2, 2017 3:49 UTC (Wed) by cry_regarder (subscriber, #50545) [Link]

That is a fairly considered opinion.

Fedora ponders the Python 2 end game

Posted Aug 2, 2017 6:04 UTC (Wed) by togga (subscriber, #53103) [Link]

Fair point. Maybe a more robust solution is not a single platform but rather a "floating" set of them with som common stable but flexible base?

Although Python was stable for a "good while" giving some nice years of productivity it seems smart to stick with something that won't intentionally or unintentionally screw you over after a number of years due to for instance one person's or company's decision (I recall having seen this before...).

Fedora ponders the Python 2 end game

Posted Aug 2, 2017 16:46 UTC (Wed) by khim (subscriber, #9252) [Link] (14 responses)

It's not that hard to "not split the Go ecosystem". FORTRAN did that (and they changed they way language is used in pretty significant way over time), C did that (with transition to C99), even C++ did that (twice - with transition to C++98 from C and with transition to C++11 which is NOT 100% compatible with C++98). Only python developers decided they don't have to have to use tried and true approach and instead would force everyone to rewrite everything.

Fedora ponders the Python 2 end game

Posted Aug 2, 2017 18:48 UTC (Wed) by drag (guest, #31333) [Link] (13 responses)

You pointed out several examples of programs being broken by language versioning in Fortran and C/C++ and then in the same paragraph claimed that the python developers are the only ones that are guilty of this.

That's very contradictory.

Fedora ponders the Python 2 end game

Posted Aug 2, 2017 19:53 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

There are degrees of breakage - nobody expects software to be 100% perfect. But C++ tried hard to preserve compatibility with C, and it was not perfect but close enough so that incompatibilities could be fixed easily. The gains were also quite major in case of Fortran and C->C++.

Py3 did a huge compatibility break that required major changes and a lot of unexpected breakages. And for no real gain.

Fedora ponders the Python 2 end game

Posted Aug 2, 2017 23:19 UTC (Wed) by anselm (subscriber, #2796) [Link] (9 responses)

I don't know. For example, IIRC there are all sorts of subtle differences between C and C++, to a point where a valid C program doesn't necessarily work the same way in C++. By contrast, it is possible to write code that works in both Python 2.7 and 3.x, and the Python developers have made changes in recent versions of Python 3.x that improve compatibility even more.

Personally I prefer Python 3 because, among other things, strings work a lot better than they used to in Python 2. Making the transition is a one-time hassle but as far as I'm concerned it is worth it.

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 0:05 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

For example, IIRC there are all sorts of subtle differences between C and C++, to a point where a valid C program doesn't necessarily work the same way in C++

That's why even today there are C parser in gcc and clang and you could link together modules written in C and C++.

By contrast, it is possible to write code that works in both Python 2.7 and 3.x

By contrast? "Normal" C code is also a C++ code, all the changes and possible incompatibilties are explicitly listed in C++ standard (annex C) and in general the "natural" case is when code written for old version works in a new version - only some odd corner-cases are broken!

Compare to python, where "normal" python 3 code is completely incompatible with python 2 and where compatibility features which allowed one to write 2/3 code only arrived later, when developers "suddenly" discovered that people are just not in hurry to spend countless hours doing pointless work for no good reason.

Python2 to Python3 transition may not be the worst type transition (PHP6 and Perl6 transition attempts were even worse), but it's certainly the worst one which haven't killed the language (PHP6 died and Perl6 haven't - but in both cases original implementation survived and are in wide use).

the Python developers have made changes in recent versions of Python 3.x that improve compatibility even more

Sure, but all that work was an obvious afterthought whiles it's certainly the most important part of any such transition.

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 9:31 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

"Normal" C code is emphatically not C++ code, because normal C code often uses malloc() and seldom explicitly casts the return value to the desired pointer type because C's implicit conversion rules say that void * is implicitly castable to any other pointer type and programmers are often lazy. C++ discarded that implicit conversion.

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 13:25 UTC (Thu) by niner (subscriber, #26151) [Link]

How can Perl 6 be worse when it's quite possible to do a piecemeal upgrade of a codebase from Perl 5 to Perl 6? If such a change is even desired instead of just combining the best parts of both languages. No Perl 5 developer was left in the rain and those who want, can use Perl 6. What about this was in any way worse than leaving people who cannot upgrade behind and forcing countless pointless man years of effort for the rest including distributions?

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 0:06 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

C vs. C++ breakage happened gradually, early C++ versions were pretty much "C with classes". I've seen million line C applications being translated into C++ by simply renaming the files and doing a few easy changes. And C is a compiled language, so that helps a lot.

And if everything else fails, you can always #include C-based API with minimum fuss even in modern C++ using 'extern "C"{}' blocks.

There's nothing comparable in Python world. The transition was abrupt and it required quite a lot of changes, and being an interpreted language you actually have to test everything.

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 0:10 UTC (Thu) by khim (subscriber, #9252) [Link] (4 responses)

Personally I prefer Python 3 because, among other things, strings work a lot better than they used to in Python 2.

Actually situation with strings is awful in python2 is awful and python3 made it even worse. Why do you think WTF-8 was added to rust? Why to you think Go still considers strings a sequence of bytes with no string attached? World where only nice unicode strings exist is an utopia! That's why they were forced to throw away the notion that file names are strings and introduced path-like objects! And I'm sure it's not the end.

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 0:37 UTC (Thu) by anselm (subscriber, #2796) [Link] (2 responses)

I can only speak for myself, but I'm way happier with strings (and byte sequences) in Python 3 than I used to be with strings (and Unicode strings) in Python 2. They pretty much seem to do what I expect them to do, and given a little care it is reasonably easy to write programs that work. Of course I may not be clever enough to appreciate how “awful” Python's string handling really is.

OTOH, I don't really care about WTF-8 in rust nor what Go considers a string because (so far) I'm not using either of those languages, and have no plans to do so in the foreseeable future.

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 2:20 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

Of course I may not be clever enough to appreciate how “awful” Python's string handling really is.

My favorite example was Anaconda few years back. Pick text installer (because you are dealing with small VM), pick Russian language and do everything. On the very last screen it tries to show you "everything is done" message which is in KOI8-R instead of UTF-8 - with exception being thrown and whole installation rolled back. Just PERFECT handling of strings.

OTOH, I don't really care about WTF-8 in rust nor what Go considers a string because (so far) I'm not using either of those languages, and have no plans to do so in the foreseeable future.

That's Ok. If your goal is scripts which kinda-sorta-work-if-you-are-lucky then python or, heck, even bash work. If you want robustness then python is not for you.

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 15:24 UTC (Thu) by intgr (subscriber, #39733) [Link]

People seem to have the wrong assumption about paths in Python 3. Python does actually properly handle filenames that aren't valid UTF-8; they are escaped with certain Unicode codepoints: https://www.python.org/dev/peps/pep-0383/ (I guess that's like WTF-8 in Rust). I think that's a pretty good compromise: it does the right thing with properly encoded paths (nearly all paths are) but still remains functional with paths that aren't.

> On the very last screen it tries to show you "everything is done" message which is in KOI8-R instead of UTF-8 - with exception being thrown and whole installation rolled back. Just PERFECT handling of strings.

Yes, that's exactly the behavior I want. There was a bug in the program (or translation) and a good programming environment should immediately throw an error, rather than proceed with some unexpected behavior. Even environments that used to play very fast and loose with types and ignore errors, like MySQL and PHP, have recently became significantly stricter. Otherwise, in complex programs, you will end up with latent errors that are much harder to debug and often data loss.

> If you want robustness then python is not for you.

Erm, in one breath you complain about Python being too strict and now you complain that it's not robust?

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 7:51 UTC (Thu) by roc (subscriber, #30627) [Link]

WTF-8 was not really "added" to Rust. There's a crate for it, that's all.

OTOH OsString has been part of Rust for a long time exactly because sometimes you need to deal with weird non-Unicode platform strings.

Fedora ponders the Python 2 end game

Posted Aug 2, 2017 23:48 UTC (Wed) by khim (subscriber, #9252) [Link]

Sorry. Thought it would be obvious from the context, but perhaps not. I mean: Mixed programs, in which packages written in Go 2 import packages written in Go 1 and vice versa, must work effortlessly during a transition period of multiple years.

Fortran 90 introduced free-form source input and arrays were redesigned from scratch (and ended up pretty bad: they were designed with Cray CPUs in mind and are not a good fit for modern CPUs) - yet old code could still be compiled with Fortran 2015 compiler! The same with C, C++ and other languages - "old style" is just a switch away and, most importantly, mixed programs, in which packages written in XXX import packages written in YYY and vice versa, must work effortlessly during a transition period of multiple years.

Fortran developers certainly learned from experience (Fortran 77 was not used widely for many years after introduction because it haven't supported some features of old Fortran 66 and thus old modules were not intermixable with new ones), C and C++ developers (and many, many, many others) have learned from it (e.g. Delphi introduced new class-style types and new strings - but old ones were available for years). That fact was certainly well-known to python community - they have just chosen to ignore all that experience.

Fedora ponders the Python 2 end game

Posted Aug 3, 2017 16:18 UTC (Thu) by smoogen (subscriber, #97) [Link]

I expect the point dropped is that every compiler toolkit will compile both for N years. The C compilers would work with both K&R C, ANSI C and C99 while emitting warnings. They would then drop K&R C or make it require an explicit flag. It then would only emit warning for mixing ANSI and C99. Then ANSI needed an explicite flag and then C99 only. All in all it pretty much took 15 years from C99 for various compilers to transition.

The same with Fortran. You could mix and match IV and 77 code. Then you needed a flag, then you needed a flag for F90 etc etc. And the same for C++ code. The transitions for each were slow and Azathoth knows how many compiler writers went mad having to work that kind of code. Which I expect that Guido was trying to avoid.