I argued on the list that these should be kept for major releases for planning reasons but they appear to be convinced it is too hard.
I know some Python Libraries break backwards compatibility (Pandas being a big one) - but, for the most part, hasn't the language been backwards compatible since at least Python 3.4? (And possibly further back, for all I know).
https://docs.python.org/3/whatsnew/index.html
Keep in mind they have deferred a number of them because of the impending EOL of Python 2.7. There are fewer breaking changes during the latter 3.X series, which should resume in 3.9 or 3.10 now that Python2 has passed on.
Here's a commonly mentioned one:
Changes in Python Behavior: async and await names are now reserved keywords. Code using these names as identifiers will now raise a SyntaxError. (Contributed by Jelle Zijlstra in bpo-30406.)
Note: I think this is a bad idea, I'd rather all these small breaking changes and parser be deferred to 4.X. But they need to be small breaking changes, of course, not a new language.
It might seem like a quibble, but it seems better to describe Python 3 as a different language versus Python 2. Newbies seem to get that.
(Or, alternatively, "How many Python 2 scripts will run on a Python 3 interpreter?" Answer: "None of them.")
And there are really few that are even near Python popularity, or used with such diversity as Python.
I mean, you can get away with keeping AWK the way it was 2 decades ago, nobody is going to use it for for machine learning or to teach computing in all universities in the world on 3 operating systems, utilizing C extensions, or processing Web API.
Among the few that would even compare, there are the ones that have accumulated so much cruft that they became unusable from today's standard (E.G: bash). Then you have those who have done like Python (E.G: perl 6). The ones that just tried and failed (PHP 6). The ones that broke compat and told everybody move or die (Ruby in a point release, gave basically 2 years). And the ones that created a huge pile of horror they called full stack to keep going (E.G: JS). Also those that got hijacked by vendors and just exploded in miriads of proprietary syntaxes (E.G: SQL) or completely new concepts (E.G: lisp).
At least, in Python you CAN write Python 2/3 compatible code, and you have a LOT of tooling to help you with that, or migrating.
So, yes, the Python 2 -> 3 transition could have been better. Insight is 20/20.
But I'm struggling to think of any other language in a similar situation that has done better.
If Python 3 had been introduced as a separate language, I'm pretty sure everyone would have said "Why isn't this just called Python 3? It's 99.9% the same as Python and it's by the same people and they're deprecating Python in favor of it."
That's obviously untrue. For example, consider the following Python 2 script:
with open('a.txt', 'r') as a, open('b.txt', 'w') as b:
for line in a:
b.write(line)
My guess is that if you sweep GitHub for Python2 code and push it into Python3, that proportion would be under one percent.
I did two migrations of >500k loc projects in an afternoon each, and admittedly some days of testing to gain confidence since there where few unit test. But i found it to be very smooth sailing.
I was very familiar with both projects, so that helped a lot.
EDIT: I also want to add that i did this using python3.5, when to ecosystem seemed to be at a sweet spot of dependencies supporting both 2 and 3 mostly. I guess if one has been waiting until now, the divide between library versions will be a lot bigger.
For some projects I did bigger refactors for 2.6/7 (exceptions) and 3.6 (fstrings).
int main(int c,char** v)
{
printf("Hello, World!\n");
return 0;
}
That is completely false. So many libraries have support both for 2 and 3. That's code that run just as well under both interpreter.
Googling quickly, I find this, which does a bit better than 2to3. I suppose one could write to a somewhat constrained intersection of Python2 and Python3, if one is willing to make at least some boilerplate changes to the original Python2 code.
https://python-future.org/overview.html
That said, if you bring a Python2 script and feed it to a Python3 interpreter, no, in general that will not work. They simply aren't the same language. Even a simple "print x" will do you in.
Sure, as long as it doesn't contain any syntax or spellings which are incompatible between the two. That's a fairly large subset of the language.
> if you bring a Python2 script and feed it to a Python3 interpreter, no, in general that will not work. They simply aren't the same language. Even a simple "print x" will do you in.
But this will work:
from __future__ import print_function
print(x)
Also, as I said above, there is a pretty large subset of the Python language that has the same syntax and spellings in both Python 2 and Python 3, and any script or module or package that only uses that subset will run just fine under both interpreters. You are drastically underestimating both the size and the usage of this subset of the language.
Yes you often need some precautions like "from __future__ import" statements and sometimes libraries like `six`, but it's been perfectly normal practice for most of the last decade.
In fact, the vast majority of popular libs had a 2/3 compatible code base for a few years.
The hard part was not the syntax in fact. It's pretty trivial: the language are not that different.
The hard part is the I/O stack, because the stdlib is very different, espacially for this part.
Nearly every py3 feature was backported to 2 you just need to write it in a compatible way. I'm seeing some drop py2 support now though. Which I'm fine with, I haven't written python2 code in maybe 6 or 7 years now.
That is not true though, a lot of 2 scripts will run no problem, especially if import future is used
Perl 6 (now Raku), of course, but they at least had the decency to admit it.
Python broke compat once in 25 years and gave 13 years to migrate.
It's a very conservative language.