Hacker News new | past | comments | ask | show | jobs | submit login

In the past I have been a vocal advocate for the way the transition from Python 2 to Python 3 was handled. However, it should be said I use Python primarily as scripting glue, e.g. for build scripts and automation tasks. I have never worked on a "large" Python code base nor did I have to migrate anything. Almost everything I had written in Python 2 was just naturally replaced by newer scripts in the due course of time.

I also remember my first forays into Python 3 and the annoyance I had at some of the decisions. I recall when they relented on the % operator for string interpolation and I agree it was a poor initial choice to leave it out. I totally agree with the author that Python 3 could have made some subtle changes earlier on to help those with massive codebases.

And I still feel it was the right move. Somehow Python is even more relevant today than it was when this painful process began. While some may say that popularity is despite missteps I actually believe the general slow and cautious push forward is one of the primary reasons Python continues to succeed. There is a balance between completely abandoning old users (e.g. Perl 5 to Perl 6) and keeping every historical wart (e.g. C++). IMO, the Python community found a middle ground and made it work.




I have yet to find out about a Python 3 change that couldn't have been handled in a backward compatible way.

I know this because every change I've heard about is reminiscent of a Perl5 change where backwards compatibility was not broken.

The transition to Python 3 was not handled anywhere as well as it could have been.

There is a reason Go2 isn't copying Python3. (Strangely they seem to be copying the Perl5 update model even though they don't realize it.)

The thing is that because Python has an unhealthy fixation on “There should only be one way to do things” they rejected things that would have made the transition easier. (Or even less necessary.)

I think it is kind-of telling that someone thought it necessary to create Tauthon. Tauthon is sort-of applying the Perl5 update model to Python 2.7.


Re: There is a balance between completely abandoning old users (e.g. Perl 5 to Perl 6)

Please note that Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media).

In the original design of Perl 6, a source-level compatibility layer ("use v5") was envisioned that should allow Perl 5 source code to run inside of Perl 6. So the plan was to actually not abandon old users.

In my opinion, this failed for two reasons:

1. Most of Perl 5 actually depends on XS code, the hastily devised and not very well thought out interface to C code of Perl 5. Being able to run Perl 5 source code in Perl 6 doesn't bring you much, unless you have a complete stack free of XS. Although some people tried to achieve that (with many PurePerl initiatives), this really never materialized.

2. Then when the Inline::Perl5 module came along, allowing seamless integration of a Perl 5 interpreter inside Perl 6, using Perl 5 modules inside of Perl 6 as if they were Perl 6 modules, it basically nailed the coffin in which the "use v5" initiative found itself already in.

And now they're considered different languages after the rename to Raku, dividing already limited resources. I guess that's the way of life.


I think my wording "abandoning" was more inflammatory than I would have liked. And I didn't want to call out or target Perl 6 / Raku. What I meant to convey was that the language team behind Perl 6 (as it was known before the rebranding) made a decision that it would be a new language and not an evolution of the existing language. It was the first example in my mind, one most people would recognize, that anchored one side of the continuum I was describing. I assume there are better examples (or worse offenders) but I don't know of any off hand.




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: