I long for the day when typing "python" into a shell will bring up a python 3 prompt
sudo ln -sf /usr/bin/python3 /usr/bin/python
Or use a Linux distribution like Arch that has python symlinked to python3 by default.
Sunsetting Python 2
181–190 of 733 posts
Re: Sunsetting Python 2
#182Earlier quoted context omitted.
No, the benefit of FOSS is that if the group developing a product does not support it anymore, you are free to fork it and support it yourself. And I am sure we will see a fair share of people doing that. What I am not sure is of anyone doing so will have the shoulders to actually support it. Python 2.7 was released 1 decade ago. That's quite a long transition time.
Tongue in cheek comment; C was released 47 years ago and is still supported... but then again, that shows a very different philosophy between system languages and scripting languages.
It's much easier for C to be backward compatible, not because it's a system language per se but rather because it's so minimalist. You don't have problems dealing with unicode when you don't deal with unicode. You don't have a problem dealing with ranges and iterators when your most advanced looping construct is for(i = 0; i Portability issues in C are mostly between architectures, not standard versions. The fact that "char" is normally signed on x86 but unsigned on ARM for instance is a common source of problems while porting code between these architectures. At least when you have python3 code you can be reasonably sure that it's going to run on any compliant python3 interpreter.
Re: Sunsetting Python 2
#183Earlier quoted context omitted.
Based on your timeline, a four year gap from "not yet ready to migrate" to "we won't fix security vulnerabilities" is very short. Python is an open source project I've used and contributed nothing to, so I don't have the right to be a back seat driver. Were it a commercial project and I was a customer, I would be quite upset.
The thing is, a four year gap is very large from the perspective of "should we drop everything else and prioritize porting our library to python3 right now". If the deadline wasn't 2020 but 2024, then you wouldn't get more time, simply we'd be at "not yet ready to migrate" state right now, as major libraries would not have switched yet.
If the only way your organization can prioritize this is either “drop everything and update” or “completely ignore and do no work to prepare,” then it sounds like Python versioning is not your biggest problem.
Re: Sunsetting Python 2
#184Earlier quoted context omitted.
It was longer than Apple’s move to 64 bit apps on the iPhone. Actually, depending on what action you pin dates to, it was twice as long. One other thing - you can’t run non-64 bit apps anymore. You can still run Python 2.
That's a pretty low bar. I still think that move by Apple was pretty terrible. Especially given that it's 100% impossible to downgrade iOS (your last point).
And it’s entirely impossible to run 32 bit apps on newer Apple ARM chips. There is always a cost to keeping old APIs or in Apple’s case, old silicon.
Re: Sunsetting Python 2
#185What surprises me about this is that the documentation for Python 2 does not explicitly say that the language version is about to be unsupported, see e.g. https://docs.python.org/2/library/zipfile.html Contrast this with the Postgres website, which tells me I'm browsing old docs (because Google still offers old links), see e.g. https://www.postgresql.org/docs/9.2/tutorial-window.html Are there plans to add a banner t…
I cannot agree enough. As a casual python user, it is quite common to stumble in some issue, after somme googling land in a doc page, try my solution, and find it does not work. Then googling after the failed solution, noticing that the previous doc page was describing a Python 2 feature that do not exists (or works different) in Python 3.
This issue is part of why Haskell is so hard to learn. Haskell's package database Hackage keeps all old deprecated incompatible versions of packages, with documentation pages all well indexed by Google, with higher page rank because they are longer lived than the current package version, with no indication that they are deprecated and incompatible with current Haskell deployments.
Re: Sunsetting Python 2
#186While the article is very "matter-of-fact" about the sunset period and what it means to those that still use Python 2, I'm still surprised that it's taken this long to finally close support. I had assumed that their approach would be to fork the language into a new language (call it something like Liasis) and to allow one of the big-name contractors that specialise on Python 2 to take ownership of it. As an aside, a…
> I'm still surprised that it's taken this long to finally close support That's because the Python community is too nice. When Ruby or node broke compat, they just said "move or die". People moved. When Python broke compat, they gave 7 years. People screamed, cried, complained, sweared it was impossible for them, that life was hard and the PSF was unfair. They got an extension of 5 more years. People still complained…
Maybe also don't make tools targeted at people who can't use proper tools.
Re: Sunsetting Python 2
#187Earlier quoted context omitted.
Probably because it's hyperbole to get a point across.
I don't know if the author was intending to be hyperbolic -- I for one prefer Python 2's print. I would've preferred keeping print the way it was and using a new keyword for the new functionality.
The change in the print statement was also what put me off from Python 3 for a long while. But back then there where also no big benefits to be had from moving to 3. Nowadays I even prefer the print function as it makes it easer to convert to log functions.
Re: Sunsetting Python 2
#188Re: Sunsetting Python 2
#189Thank God. It's been really annoying having to add parenthesis to all the print statements when I accidently download a python 2 script.
Re: Sunsetting Python 2
#190Earlier quoted context omitted.
You couldn't switch to Python 3 until the middle part of this decade unless the stars aligned with your dependencies, the library support wasn't there. And the first releases of Python 3 were glorified betas, the first "usable" version of Python 3 is often considered to be version 3.3 released in 2012.
But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy. You also could have contributed to your dependancies to help them become Python 3 compatible.
> But you could easily write Python 3 compatible code so that upgrading once your dependacies were ready was easy.
This sounds a bit like telling someone, oh, you could've easily started driving an EV, so that once charging stations were actually out there, you'd have been ready...