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)
It works identically on a Python 3 interpreter, and it doesn't even use "from __future__ import ...".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;
}
doesn't make C++ the same language as C.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)
This is valid under both Python 2 and Python 3.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.
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.")