This is awesome in terms of avoiding all of the weird things when a person typed pip rather than pip3 and module didn't seem to get installed anywhere. That said, watching perl trying to kill perl5 with perl6 (unsuccessful) and python trying to kill python 2 with python 3 (more successful) it struck me how ridiculous it is that open source languages have to put up with this. Clearly "major" numbers are insufficient, the only real answer is to rename the entire freaking language when you make incompatible changes to it.
I'm in an awkward chain of dependencies. You see, in my industry there are very few players, and the current version of their software depends on much functionality and rather exacting specifications from products which are made using ArcGIS 10.2.1. Not 10.2. Not 10.2.2.<p>This is a very conservative hunk of software because this is not a "move fast and break things" industry. This is a "people die when we screw up" industry. So they haven't moved from ArcGIS 10.2.1 for our version. Change <i>is</i> coming but they have to be careful.<p>So ArcGIS 10.2.1 comes with a python install of 2.7.2 (I am pretty sure it is .2). And you are very strongly advised NOT TO UPGRADE THAT in big bold letters on the relevant help pages. So I need to use 2.7.2 to manipulate some stuff out of ArcGIS 10.2.1 to do "stuff."<p>And there I sit.
It's telling that there are a number of commercially available Python libraries targeting enterprise customers for which the Python 3 version is free, but there's a hefty license fee for the Python 2 version. Maybe that's an appropriate tax on sluggish software/IT departments.
I managed to avoid Python 2 for nearly 3 years now in my projects, I think it is time to get rid of it for good and use the new freedoms to improve the tooling.<p>It is so ironic that in Python the most "unpythonic" thing is the version management of the language and libraries etc itself.<p>Something like python poetry, venv etc are great steps into the right direction, but there should be an official solution that "just works" and is predictable.<p>When I give python courses I usually skip dependency managment and explain it in the very end because it would probably (rightfully so) break the will of everybody involved. It shouldn't be like that
The worst thing that happened to Python was rhat Linux distros not only shipped it but used it pervasively for scripting. Thus replacing Py 2 became a huge problem.<p>Until recently it was easier to set up for Python dev on Windows because you could download a clean Python and not worry about broken Pythons on your path.<p>Microsoft wrecked it all last year by including a system Python and they'll probably play games to keep it in front of your Python on the path.so you will be typing pip3.7, pip3.8, pip-3.6-pypy, etc. for the rest of your life.
Since the Python2->3 migration discussion is being had again here, I'd just like to advertise my compatibility library that can help with migrating old projects: <a href="https://github.com/mbarkhau/lib3to6" rel="nofollow">https://github.com/mbarkhau/lib3to6</a>
I'm more annoyed for the "Drop support for Python 3.5" than the first one. There are a few codebases I maintain where I already had to pin the pip version because the machine runs python 3.4, and then pin other package versions that did drop support for older python3 versions.
I have a background in systems engineering, working on a commercial operating system. I code in several languages. To me, it’s just a given that adoption extends the lifetime of something, even if it is not under active development. There’s a strange phenomenon with Python in particular, where it is upsetting for some reason to be told that Python 2.x will still be in use after we retire. To me this is just the natural way things work. There is so much stuff out there using Python 2.x where there’s no programmer around to do porting work and because things work, there’s no reason to invest. Normally when this sort of thing has happened to say, a language like VB, it doesn’t really matter because the end result is something compiled with a runtime. As long as the environment the app runs in has consistent behavior (app compat) there’s nothing to do. But with Python that isn’t precompiled you need the toolchain and dependencies. Python 2.x isn’t going anywhere, so I think Pip will ultimately have to keep and “freeze” support for Python 2.x, rather than not supporting it. If you are reading this and infuriated, perhaps ask some old hands you know, instead of taking my word for it. Flash is perhaps the closest example I can think of. Flash was “over” ages ago but browsers have had to keep support for an awful long time.<p>I give their decision a week before they revert and come up with an alternative.
I don't really use Python much any more, and haven't for a couple of years. I may have some Python projects coming up later this year though. What's the current recommended way to deal with Python versions and isolating dependencies? Are there any good tools that simplify virtual environments &c or am I best off just installing my required Python and packages in a Docker container?
Python 2 has some value Python doesn't have. E.g. there are Python 2 builds for really old platforms. There even are some considerably exotic platforms which are not so old and not deprecated but still don't have Python 3.
One thing that might be important to note about this: to the extent that pip is a client for PyPI, a strategy of freezing the last supported version of pip indefinitely may not work. It will presumably always be able to install Python 2 wheels from a local wheelhouse, but it's worth being prepared for a future where `python2 -m pip install <x>` stops working.
Just upgraded motioneye[1] Python 2 yesterday via pip, have been porting other smaller Python 2 projects to Python 3 for personal use for a while now.<p>But there are still large projects like motioneye where Python 3 port is WIP or not planned all.<p>[1]<a href="https://github.com/ccrisan/motioneye" rel="nofollow">https://github.com/ccrisan/motioneye</a>
I am mostly a hobbyist dev, and the transition from Python 2 to 3 has been rather painful.<p>I have had to rewrite several projects, just so they could continue working.<p>But I understand the need fot it. So iam not bitter or anything
FWIW...<p>> How long will PyPy support Python2?<p>> Since RPython is built on top of Python2 and that is extremely unlikely to change, the Python2 version of PyPy will be around “forever”, i.e. as long as PyPy itself is around.<p><a href="https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-support-python2" rel="nofollow">https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s...</a>
A lot of research has been released with assets written in now defunct versions of Python. It is a shame that the barrier to reproduction just went up a lot.<p>One would hope that language designers would make the languages monotonically increasing to preserve compatibility and otherwise fork not projects when they loose confidence in previous features.
I work in CGI and I'm happy to see Python moving forward, I'm so sad CGI is still lacking of broad Python 3 support. This industry was top notch 10 years ago but its inability to handle Python 3 migration since <i>years</i> despite its ubiquitous usage make me realize it's no more an industry driving domain.
Common Lisp was a choice that many teams chose to ignore for whatever reasons. The price of perpetual upgrades is apparently cheaper than starting with a complete and stable language.
I only rarely use Python (Ruby, Go, R and Bash usually do whatever I need) and I've never gotten my head around the whole Python 2 vs 3 thing. For a language often touted to be the best language for novice programmers, I think it's odd to expect them not to get caught with their metaphorical pants down in that dichotomy.<p>Edit: I should probably clarify. I have nothing against Python, quite the contrary, I've just always found that version 2 vs 3 thing odd.
yet on my newest and best ubuntu20.04 when you type 'python' you are still running python2, which I don't use, will we ever be possible to use python as python3 by default,it's annoying.<p>let python be python3, and python2 for python2 instead
I don’t have a problem ideologically with the maintainers doing this since 2.7 is EOL, but making a breaking change like this over the weekend was kind of cruel.
Good. Django moved the needle to improving python3 adoption just by moving their docs to include only python3 snippets. So this is another important step.
I still can't get why they replaced: `print "abc"` with `print("abc")`.<p>Python REPL was my go to shell calculator and it is quite elaborate to put the parentheses around what I would like to print, for me that was the main drawback of python3.<p>But I don't write production code in python, it is used only for small shell scripts, or like calculator.
Just like Visual BASIC 6.0, dropped for Visual BASIC.Net and Visual C#.Net because of progress. You can't expect a language to last forever or support to last forever.<p>Now Python 4.0 is coming out, and soon Python 3.X will lose support.