I get that enterprise-y stuff is on a more LTS slow schedule, but:
Python 3 was released a DECADE ago - literally. If you've got mission critical stuff running on Python 2 and are panicking now then it's time re-evaluate your life choices.
Python 3 was released a DECADE ago - literally. If you've got mission critical stuff running on Python 2 and are panicking now then it's time re-evaluate your life choices.
This has required a lot of engineering work to make libraries function with Python 2 and Python 3 (e.g. pandas, numpy, scipy), to make frameworks work properly on both (e.g. django), and to ensure that the libraries that everything relies on (e.g. mysqldb) get updated, forked, or replaced with rewritten alternatives.
Sure, I as a developer "should have" been writing Python 3 for the last ten years, but for most of those years it would have required rewriting large libraries that I, and other developers, rely on to be productive.
Unfortunately this has meant that instead of starting Python 3 projects over the last ten years, people have been starting Python 2 projects so that they could get their work done in those intervening years.
I don’t do a lot of Python, and have been exclusively using v3, but I thought you could make your Python 2 somewhat compatible with v3 by using libraries, etc.
How close can you come to a Python code base that runs in v2 and v3?
Using the `six` module, this is (nearly) trivial for 99% of code. If you're doing certain weird things, its more difficult but possible. (I say this having done py2-3 conversion or dual support for lots of vanilla code, as well as a significant amount of weird code: c/c++ extensions and code that uses advanced features like code object introspection and dynamic imports/rewriting/etc).
I moved to futurize for some libraries -- its like writing python 3 that will run on python 2.
I am looking forward to dropping python 2 support on libraries I maintain.
Porting isn't really as trivial as you make it sound, either.
Joke on them, some extensions you listed didn't even wait until 2020 and already dropped Python 2 support.
We've got some projects based on abandoned libraries that will never be upgraded to python 3, essentially leaving us paralyzed on python 2. These projects were also meant to be deprecated a decade ago so no path forward was ever created, but they cling on to dear life.
Fair - the 2-->3 transition was indeed painful. So 3-5 years actual migration window, with advance notice of "Python3 is coming of another 7-5 years".
Whichever way you look at it - that's a decade advance notice. In a industry that moves exceptionally fast.
If you want to judge me as "dismissive arrogant attitude" for that - so be it.
>people need to question their life choices for being cautions.
The life choices phrasing was a poor choice on my part & I apologize for that. Message is unchanged though. To me waiting till support window runs out and then thinking of next step is the exact opposite of "being cautious".
I don’t think you fully grok the risk of code changes in some of these large legacy systems. EOL with no security patches on a closed system that processes trusted inputs is nearly 0-risk.
Oh I get the risk. What I don't get is someone sitting on this for a decade and at EOL starting to wonder how this is gonna work.
>nearly 0-risk
That's cool to. I mean there are *nix servers with years of uptime that haven't seen a proper update since ever. All good (sorta).
I coded in Python 2 last week - nothing against it. It's the bizarre "this decade long transition just snuck up on us" tone of the question that gets me.
There is a lot of industry specific software out there that runs on all sorts of odds and ends of versions of stuff. Some critical software for a particular industry I'm aware of, still relies on CentOS 4, for example. It can't cope, and isn't certified to run on anything newer.
The end users often find their hands tied, because there's only one vendor producing software that fits their needs, and those vendors rarely give much of a damn about their end users running out of date software that doesn't get any security patches.
That shouldn't turn into a "so redhat why the hell aren't you supporting decade old tech".
The solution here is to shout at the shitty suppliers not crap on redhat for their (reasonable) support cycles.
...decade advance notice...still gets caught out.
Dismissive. Fk yeah.
Linux’s staying power has a lot to do with the policy of “don’t break user-space”
I'm happy to be able to drop Python 2 support in my projects, but I've had to hold off on some of them that run on RHEL / CentOS.
Like good luck running Python <3.6 without string interpolation, released in December 2016.
All of this is entirely their fault, particularly with Perl hindsight.
Using Ansible against Python3-only targets used to require manually setting ansible_python_interpreter in the inventory, but since 2.8 also supports automatic interpreter discovery.
And some features such as redis cache were broken on python 3
Yes I understand that. Legacy code is a pain.
This transition is a decade in the making though. A decade.
Ansible is SEVEN YEARS OLD.
This is not a flaw in the python support / timing model. Decade is practically glacial in software terms. Anyone not keeping pace is on their own imo.
Fun fact...py2 EOL was initially 2015. This is already the bloody extension...
the only thing that's weird to me is if you have C extensions, it's super easy writing tests for those in Python. getting coverage is possible via gcov/lcov. retrofitting tests is hard and painful in any language, period. but so is a rewrite. pick your poison.
I don't think that's really true. Yes, our overall product is a mixed language codebase, with most of the core functionality in C. But quite a lot of the business logic lives in Python. The C modules are all just manually implemented wrappers of C libraries (as opposed to, say, rewrites to speed up slower Python hot paths).
By sheer quantity, it's something like 110k lines of manual C wrappers and 2.0 million lines of Python2. So from a numbers perspective, it seems like the Python part is very much a Python codebase. (Though the whole product is about 19 million lines of C, 3 million lines of C++, and negligible percentages of other languages beyond Python2.)
> if you've ended up with that many C extensions, Python probably wasn't the best fit to begin with.
Not sure I'd agree with that, either :-). Although I guess it depends on how you define "begin."
The initial manual wrappers were written in the early 2000s. At the time, Python (like, version 2.3?) made a lot of sense for CLI / business logic / initial web interface backend, interacting with the core libraries via the wrappers. It's not like any of the contemporaneous languages the original authors (now long gone) could have picked would have fit better or held up better over time. C++98 isn't the C++1y we have today and simply isn't a replacement for Python; other scripting languages were demonstrably worse (Perl, Tcl, ...). I don't know why those folks chose to manually implement wrappers (maybe it predated SWIG), but it's what we're working with now.
> the only thing that's weird to me is if you have C extensions, it's super easy writing tests for those in Python.
Same as anything else, really. If your code is pure algebraic functions, unit testing is trivial; if it has lots of system-level side effects or isn't decomposed into testable units, it's difficult to retrofit.
> retrofitting tests is hard and painful in any language, period. but so is a rewrite. pick your poison.
You're not wrong :-).
This is all you need to know: Python3 broke "Hello, World!"
It doesn't get any more fundamental than that.
Print the words
hello, world
99% of Python programs before Python3 was announced used the print statement.
Python3 broke 99% of existing programs.
And your rebuttal is there are---now---nontrivial programs that run in both languages? How many of those nontrivial programs existed before python3 was announced?
Zero. Zero programs like that existed.
This historical revisionism astonishes me. Just because it is now, after the fact possible to write programs that behave the same in both Python2 and Python3 doesn't mean that they are the same language.
$ cat hello.c
main()
{
printf("hello, world\n");
}
$ cc hello.c
hello.c:1:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main()
^
hello.c:3:2: warning: implicitly declaring library function 'printf' with type
'int (const char *, ...)' [-Wimplicit-function-declaration]
printf("hello, world\n");
^
hello.c:3:2: note: include the header <stdio.h> or explicitly provide a declaration for 'printf'
2 warnings generated.
$ ./a.out
hello, world
$ uname -a
OpenBSD foo.example.com 6.2 GENERIC.MP#0 amd64
Grandparent 'takeda is just flat wrong. hello.c compiles and runs with extremely modern Clang and GCC versions (8.0.1 RC and 9.2.0, respectively). The former is a development RC and the GCC was released August 2019.
And we can expect this going forward! The C standard is extremely stable and loathe to deprecate anything. gets(3) is finally gone in C11 and it has been deprecated since the 1999 standard. That's the only ABI removal in C history.
There is absolutely no reason to expect that tiny program which doesn't invoke gets(3) to ever stop being compilable by standards-conforming C compilers.
print("Hello World")
Works on both
Here's another example of a program that runs in Bash, C, C++, Obj-C, Obj-C++, Perl, PHP, and Ruby: https://codegolf.stackexchange.com/a/7280/4545
Python 2+3 is less extreme, but still: those nontrivial programs that run in both environment are just polyglot programs that happen to run in two different scripting languages.
Given the experience with Python 2->3, is there any reason to trust the PSF not to make a similar mess with a 3->4 transition? That's my concern porting any Python2 code to 3. Are Python.org done making huge API breaks, or will they do it again?