Pip has dropped support for Python 2

https://pip.pypa.io/en/stable/news/#id1

by groodt • 5 years ago

774 643 5 years ago

pip.pypa.io

hprotagonist4• 5 years ago

A nearly 13 month grace period beyond EOL seems quite generous to me.

dwheeler7• 5 years ago

Usually yes. But almost all language transitions are easier than the Python 2->3 transition.

hprotagonist4• 5 years ago

a decade's worth of grace period, on the other hand, is probably too generous.

mumblemumble3• 5 years ago

At this point, I swear, the main source of difficulty in Python 2->3 is all the foot-dragging in migrating to Python 3. I wouldn't be at all surprised to discover that vastly more Python 2 code was written in the past twelve years than in the preceding eight.

philderbeast4• 5 years ago

Python 3 was released in 2008, it had 12 years of legacy support before going EOL, and then an additional 12 months of support after that.

If 13 years isn't enough warning to migrate your use case, no amount of warning will help you.

At some point you have to stop saying its to hard to migrate.

smitty1e• 5 years ago

Whereas the Perl 5.8 upgrade pretty much killed the language.

melling• 5 years ago

Let me quote myself from 7 years ago.

“ It's kind of disappointing that developers aren't self-aware enough to understand that they are essentially screwing themselves by not moving quickly in dropping "legacy" support.

"Python 3 will be available in 2008 but we understand that you won't use it for at least 5 years."

There's an entire class of developers who won't upgrade until they absolutely have to. There's also a class of administrator that won't upgrade their current PC browser from IE6-IE8 until they absolutely have to. Developers are basically screwing themselves by not drawing a firm line.”

https://news.ycombinator.com/item?id=7372913

aidenn0• 5 years ago

I literally just ran a script that will only work on python 2.3 or older (as in it won't run on python 2.4). I don't need to worry about pip support because I'm pretty sure the script is older than pip, but it's not like old code magically disappears and it's replaced with newer code.

hprotagonist4• 5 years ago

right! pip 20.x will support py2 for ever!

mrweasel3• 5 years ago

Couldn’t you just fix it?

atoav2• 5 years ago

Don't worry, at one point running the code will become more complicated than writing new one, until you reach that point you can carry on (constantly monitoring for vulnerabilities that have been fixed in newer python versions of course).

benhurmarcel• 5 years ago

That script is 17 years old, and will probably continue working for a while. It's not bad support for a free language.

adamc3• 5 years ago

It's not a question of generous or not generous. If the work to migrate to 3.x was too great before, this won't change that -- they will just manually install libraries without pip. Or find another tool.

I suspect many python 2 shops will maintain the old and move to something else for the new. Maybe the "new" thing will be Python 3, but I expect this will give other languages opportunity, because people do have emotions, rational or not.

lootsauce• 5 years ago

The length of this dual language transition period is a travesty and an incalculable waste of money and time. They dragged this out for more than a decade. That’s the problem, people just got used to there being two versions. Should have just ripped the bandaid off way sooner.

hobofan• 5 years ago

There were too many breakages (and performance regressions in the early 3.x versions) to force a quicker transition, which would likely result in no one upgrading at all.

One option could have been to spread the brraking changes over multiple versions, but given the bad state of version/dependency management in Python, this would have likely been a clusterfuck too.

Best option would have probably been to have a longer period of RCs and only release 3.0 with the performance regressions fixed. The myths around the slowness of 3.x (especially for scientific libraries) stuck around for a very long time after they were fixed.

wmichelin• 5 years ago

Good riddance! The fact that we're still supporting Python 2 at all in 2021 is madness.

GNU_James4• 5 years ago

Friendly reminder that entire scientific community runs on Python 2 legacy code and nobody will rewrite it to Python 3.

jennyyang• 5 years ago

At some point it will be selectively rewritten if it's important enough.

hprotagonist4• 5 years ago

not in my neck of science python (biomed/neuroscience; computer vision). We've been substantially more aggressive about moving to 3 than other python neighborhoods! Look at the top projects at https://python3statement.org/, for example.

Hell, numpy 1.20.x is dropping support for anything below 3.7!

I started doing science python in 2015 on 3.5.x, never had to touch 2.x at all.

Q6T46nT668w6i3m• 5 years ago

This is absolutely untrue.

geofft4• 5 years ago

I mean, huge chunks of the scientific community run on MATLAB or Fortran. (Also... are you actually managing to get new students to install Python 2 on their laptops, somehow? And no enterprising undergrad is just like "I will just make this work on Python 3 because that's easier"?)

canofbars2• 5 years ago

No one will do it until it becomes painful enough to not do it. Killing support in all of the tools is the only way to make it happen.

orf15• 5 years ago

That’s absolutely not true though.

tootie• 5 years ago

I inherited a ton of python 2 code. Am I screwed?

awakeasleep2• 5 years ago

Imagine if your car broke down monthly, and you could afford to fix it, but buying a new one would put you into an uncomfortable amount of debt.

Screwed? No. Terribly inconvenienced, yes.

This is assuming you have enough other stuff to do that you cant afford the “debt” of migrating the python2

tcbasche• 5 years ago

Having worked with a huge Python 2 codebase recently, it's fine[1] but just becomes painful regarding dependencies. It just means you'll never have the latest versions of things.

My advice would be to gradually port what you can using six (https://pypi.org/project/six/)

[1] Fine in the sense that, the code will still work

wruza• 5 years ago

And the fact that we still periodically trap the efforts of thousands of smart people and bury it alive is insane. When told that something will only live 5 years we turn it down. When told that something 5 years old is now obsolete, we celebrate.

The definition of insanity is doing the same thing over and over again and expecting a different result. (c)

erichocean• 5 years ago

Looks like Pip 20.0 will have a long life…

at_a_remove6• 5 years ago

I couldn't get pip to work with my stock install of Python that came with my, ah, daily driver.

dleslie• 5 years ago

I have a bunch of old toolchains that use pip and python 2; I guess I'm screwed if I didn't already create a vm or docker image.

icegreentea24• 5 years ago

Old pip will continue to work just fine without dockerizing or VMing.

cable26002• 5 years ago

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.

Now Python 4.0 is coming out, and soon Python 3.X will lose support.

Znafon• 5 years ago

Python 4.0 is not coming out, the next release is 3.10

GNU_James4• 5 years ago

Do we really need "progress" in software that just werks?

bolangi• 5 years ago

Some people want Unicode support.

wvenable• 5 years ago

Dirty secret: There is plenty of multi-million dollar VB 6.0 software still running out there in the world.

I think it's not even possible to compile it without a Windows XP VM but the output still runs on Windows 10.

Microsoft honestly should have provided a compatible version of Visual Basic that would run in the .NET environment instead of VB.NET. That would have allowed much more software to move over than what actually happened.

saurik• 5 years ago

I dont know if you are being carefully specific about "compiling" as opposed to generally using the tooling (and maybe using P-code), but you can run Visual Basic 6 on newer versions of Windows. I have a machine with it set up, actually, as a researcher friend of mine inherited such a codebase. Here is an example set of instructions, not that I have read or vetted them (I don't remember what guide I had read to set it up).

https://itman.in/en/how-to-install-visualbasic-6-ide-on-wind...

flomo• 5 years ago

Microsoft's OS division has essentially committed to supporting VB6 apps forever. I imagine that RedHat and etc will do that with Python 2, too much of the world is running on it.

(VisualBasic, like Python was the most popular programming language of its day and found its way into a lot of niches which are not developer-centric.)

cable26002• 5 years ago

So it is like COBOL on a Mainframe? Too costly to convert into a Microcomputer modern language but cheap enough to run in COBOL.

I had no idea that VB 6.0 has so much support for it.

Ceezy• 5 years ago

Common are they suppose to support python 1? Every languages has breaking change at some point. People needs to move on.

userbinator2• 5 years ago

How common is Python 1.x? Was 2.x backwards-compatible with 1.x? I don't know, but my suspicion is that it was.

uranusjr3• 5 years ago

It was not, although they are indeed considerably less different from 2 to 3 and easier to migrate.

Blikkentrekker21• 5 years ago

Every languages has breaking change at some point.

This is where you are quite wrong.

Many languages and other software projects take backwards compatibility quite seriously.

Backwards compatibility is far more interesting to many clientele than the quality of the language itself. — the idea that one would have to rewrite one's codebase again later with all the potential regressions that that might lead to is not an appealing prospect.

Planes would crash if the software that ran airports would have to do this.

pjmlp12• 5 years ago

They do, but you are yet to find one example in the mainstream languages that never did at least one breaking change.

CJefferson2• 5 years ago

Gcc will, still run c89, c++98 and even fortran66 code. There has never been any suggestion support for these older versions be removed.

Packaging Python 2 & 3 together, like gcc, would have had another big advantage -- it would have meant early on I could assume everyone had Pythkn 3. There are still, plenty of macs with 2 but not 3 by default.

user59944617• 5 years ago

Well, there hasn't been a C standard after c89 so it's hard to move forward. In theory there is a c99 standard but it was never adopted by MSVC so good luck with that (that is a long story on its own).

On the C++ side, C++ didn't get more spec until C++11 (2011), then it took a decade to be supported by compilers. Imagine how long it takes to roll out a language/library change when compilers themselves are on a 3+ years release schedule.

Either way, the C++ world is heavy on proprietary extensions and tools. There is little care about standards. The standard itself is hard to consider a standard, all it does is suggest tens of new features -some of which are impossible to implement- that may be added one by one over the decade.

qwerty456127• 5 years ago

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.

filmor• 5 years ago

Any example of this? Python's C code base has very few requirements on the platform, and I doubt that got worse with the 2->3 transition.

dataflow3• 5 years ago

Not a direct response to your question, but given even Windows XP isn't supported by Python 3 as of 2015 (just 1 year after XP extended support ended), it does seem like Python does have a fairly nontrivial set of requirements for the underlying platform.

eesmith3• 5 years ago

https://github.com/python/cpython/commit/b71c7dc9ddd6997be49...

  commit b71c7dc9ddd6997be49ed6aaabf99a067e2c0388
  Author: Victor Stinner <victor.stinner@gmail.com>
  Date:   Fri Oct 10 11:55:41 2014 +0200

    Issue #22591: Drop support of MS-DOS

    Drop support of MS-DOS, especially of the DJGPP compiler (MS-DOS port of GCC).

    Today is a sad day. Good bye MS-DOS, good bye my friend :'-(

Abishek_Muthian2• 5 years ago

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.

But there are still large projects like motioneye where Python 3 port is WIP or not planned all.

[1]https://github.com/ccrisan/motioneye

agucova• 5 years ago

There is a python3 branch, some issues around the topic and a PR [1] preparing for a transition.

[1] https://github.com/ccrisan/motioneye/pull/1978

Abishek_Muthian2• 5 years ago

Yes there are, this[2] WIP PR is by the maintainer himself. It will be a while till the port is complete.

[2] https://github.com/ccrisan/motioneye/pull/1572

rnestler• 5 years ago

According to the contribution graph (https://github.com/ccrisan/motioneye/graphs/contributors) it was started in 2013 when Python 3.3 was already released. So what where the reaosons the project started in Python 2 in the first place?

phendrenad2• 5 years ago

Just started a new app using Python 2.7.19. Is switching to 3 worth it?

Xavdidtheshadow• 5 years ago

Definitely. Python 2 is EOL and will no longer be getting updates. The upgrade is easy, especially if you don't have much code written.

jefftk• 5 years ago

Yes. Python2 will get harder and harder to maintain as a dependency. You're fighting the whole ecosystem at this point.

tkuraku• 5 years ago

Python 2 is end of life. Python 3 should be the only option for new projects. Python 3 is great.

detaro• 5 years ago

Yes, starting something new in 2.x really doesn't make sense anymore outside very very special circumstances.

loeg• 5 years ago

If you're considering switching languages, maybe consider other options outside the Python family as well.

xxpor3• 5 years ago

I'll go further than the other commenters: starting a brand new project in python 2 at this point is engineering malpractice.

willis9368• 5 years ago

As is starting a project in python 3.

philderbeast4• 5 years ago

switching isn't just worth it, I would say its mandatory.

there has been no reason now for years to start any new project in python2, and since it went EOL last year you would have to be crazy to use it.

at_a_remove6• 5 years ago

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.

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 is coming but they have to be careful.

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."

And there I sit.

mumblemumble3• 5 years ago

Well, the good news is, Python 2.7.2 still works, as does pip 20.

If you haven't already, I'd recommend setting up a PyPI proxy and backing it up. I don't know what PyPI's policy is around supporting old packages or versions of the package manager are, but I have learned the hard way from working on other legacy software stacks that things have a way of disappearing from the Internet when you're not looking.

at_a_remove6• 5 years ago

Well, Python 2.7.2 works, but I have never been able to get pip to work at all in my install. Instead I get a circular chain of dependencies ...

So if it isn't in the standard library, I haven't been using it. Pity, because lxml seems like it would solve some of my issues.

wolf550e• 5 years ago

That's a version of python that does not send SNI when opening TLS connections, so sites that don't have a dedicated IP address for the domain cannot support TLS with such clients, and most sites that do have a dedicated IP address won't support TLS "just because" (no SNI - get self signed dummy cert or closed connection).

So the first thing I would have to do with such Python is monkeypatch ssl.

at_a_remove6• 5 years ago

I had sort-of traced down the problem to something involving SSL, but I am glad to see that someone else has confirmed it. Thank you.

Sadly, I have no idea how to monkeypatch SSL.

cool-RR• 5 years ago

"And there I sit."

There you chose to sit.

mrweasel3• 5 years ago

But that’s beyond conservative, Python3 isn’t new, it’s more than a decade old at this point.

I can understand that in some industries you don’t easily upgrade, because of testing and certifications. It’s however also possible to put of upgrades for so long that it becomes reckless. If you’re stuck on Python 2.7 in 2021, and your code could kill people, you’re putting people in danger by being reckless.

I’ve also seen people claiming a need for stable platform as a reason to not upgrade. Well, running Windows Server 2008 in 2021 you indeed have a “stable” platform, but it should come as no surprise when modern protocols and encryption isn’t working.

pjmlp12• 5 years ago

Yesterday in the Java thread I mentioned having done some Java 1.4 stuff in 2016.

The customer was running Red-Hat Enterprise 5.0, and it was going to stay that way as long as Red-Hat would be willing to support it.

at_a_remove6• 5 years ago

Oddly, not killing people is the reason for the very slow iterations.

jacquesm7• 5 years ago

If you’re stuck on Python 2.7 in 2021, and your code could kill people, you’re putting people in danger by being reckless.

It's comments like this that make me very sad for the software industry as a whole.

No, he's not being reckless and he's not putting people in danger. The people who make breaking changes to languages, APIs, operating systems and libraries are the ones that put people in danger and that cause others to stop upgrading because they quite reasonably fear breaking changes that could have far reaching consequences.

The price of backwards incompatibility is poorly understood.

cactus2093• 5 years ago

Saying that it’s been more than a decade is not exactly fair. Yes the language was out then, but it took a while for even for basic practices like 2 and 3 compatible code bases to emerge, and for any of the most popular libraries to support 3. Even 5 years ago, maybe even 3 years ago the “is it compatible with py3 yet” page still had some non-trivial gaps.

So it’s not like it has been feasible for most projects to migrate for a full decade, it’s only been a few years.

ashurov• 5 years ago

Same problem here..

nwallin• 5 years ago

I work for Esri, but I specifically work on ArcGIS Pro which has shipped with python 3.x for quite a while. (since before I joined the company anyway)

ArcGIS 10.2.1 comes with 2.7.5, [1] and is very, very old. It was released in Jan 2014 and hit EOL in 2019. [2]

All not-EOL versions of ArcGIS Server support python 3.x. But if you're using ArcMap, upgrading to a later version will not move you to python 3.x: you'll have to migrate to ArcGIS Pro for that. (note for the unaware: this is not a "well just buy the more expensive thing" post. ArcMap and ArcGIS Pro share the same license.) I recommend migrating to Pro for this and other reasons, but I understand that a lot of orgs don't have that on their roadmap.

Out of curiosity, is there a technical reason why your org isn't using a supported version, or is it an "ain't broke" situation? I'd ask migrating to ArcMap to Pro, but if you're on 10.2.1... yeah.

[1] https://support.esri.com/en/technical-article/000013224

[2] https://support.esri.com/en/Products/Desktop/arcgis-desktop/...

a1studmuffin• 5 years ago

Hang on a second, you consider Jan 2014 to be "very, very old"? Commercial software often has dependencies on libraries going back decades.

at_a_remove6• 5 years ago

Yes, the technical reason was outlined above. Our Big Software Vendor in the field depends on specifically the products of 10.2.1. They're extraordinarily clear on that.

So I assume that the geodatabases, the address locators, and such are all the sticking points in terms of the "products" of ArcMap. I suspect that sometimes their software dips into that specific version of arcpy, as well.

Until the vendor hops, we cannot hop. It's a problem that will be eventually fixed, but I bring it up because many people here at HN think of greenfield development often, and also in industries where tons of iteration are met with approval.

ianhanschen10• 5 years ago

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.

I give their decision a week before they revert and come up with an alternative.

Wowfunhappy7• 5 years ago

I agree with you insofar as, Pip made the wrong decision here, and they really should walk it back.

But I don't think that they will. Who is going to make them?

ianhanschen10• 5 years ago

If history tells us anything, the forcing function will come in the form of lots of noise once deployments begin to break.

dmitryminkovsky2• 5 years ago

I don't understand: why can't people just use the last version of Pip that supports Python 2?

geofft4• 5 years ago

Old versions of pip do support Python 2.x. Nothing is preventing you from using them.

There is also a straightforward way of "compiling" your code - install all your dependencies into a virtualenv, tar up that virtualenv, and untar it to the same path on the next system. I've seen this system used to work around pip and Python upgrade complexities that already exist, even within Python 2 alone, and it works fine. Then you're insulated from both changes to pip and changes to the actual packages you're trying to install from pip.

Edit to answer your question because someone downvoted me and now HN is preventing me from replying: I don't think you'll need to do anything special. The common case, honestly, is that you already have some version of pip shipped with your system (e.g., you're using Python and pip from your OS) - just keep using that version, because by definition it's a Python 2-compatible pip. The official Python 2 binaries bundle a version of pip which is also by definition Python 2-compatible.

If you need to upgrade pip for some reason, you might need to specify a version constraint on it, e.g.

    pip install -U 'pip<21'

But you also might not, because there's a way for packages to declare what Python versions they're compatible with, and so pip can take that into account when deciding what to resolve. (The trouble is that very old versions of pip, such as those bundled with LTS-age OSes, don't know how to do that, so they're going to try to upgrade to the newest possible version of pip. Less-old versions of pip running on Python 2 should, I believe, not upgrade to an incompatible version.)

ianhanschen10• 5 years ago

Would I have to do anything special aside from installing an older version? I’m not familiar with the back end of pip - in particular whether it talks to a package server or not.

chipx86• 5 years ago

That's correct, and I've verified it with modern versions of pip for Python 2.7 and 3.x. `pip2.7 install -U pip` just grabs pip 20.3.4 and installs it, ignoring pip 21.0.

pip and the legacy easy_install both access the "simple" list for a package when determining download options. This is a basic HTML page with links to all public versions of a package. Here's pip's: https://pypi.org/simple/pip/

These links contain Python version specifier information, which pip can use to select an appropriate version. For pip 21.0, that specifier is ">=3.6", so any modern pip will know it can't be used on a Python prior to 3.6. It will therefore fall back to the nearest version that provides a compatible specifier.

Looks like this was implemented starting in Pip 9.0 (at the end of 2016). From experience (my product is written in Python), there are plenty of enterprise installs that still use much older versions of pip than this. Those will grab pip 21.0 or newer (I just confirmed with a copy of pip 8).

I know for us, that'll be important to document. We still support Python 2.7 in part due to slow-moving enterprise installs, and I'm sure we're not alone in that. So geofft's example for forcing installs to <21 is exactly what a not-insignificant number of people will ultimately need to do.

rleigh2• 5 years ago

Don't forget about native dependencies. Any Python module that embeds native libraries needs to remain binary compatible with the host system. And because Python doesn't control this in anyway whatsoever, it's a lottery if things break on a current system, let alone an obsolete virtualenv one where the chances are even higher.

joiguru• 5 years ago

Self contained containers (like singularity) have come up to fill this gap. Since a few years back we have started investing in creating these containers at the end of every project, as it is becoming increasingly hard to depend on dependencies remaining available online indefinitely.

SOLAR_FIELDS• 5 years ago

That is a fabulous idea. I would love it if that became the de facto for newly published scientific papers - here is the source code and here is the container that we used to run it. Ultimate reproducibility.

zzzeek3• 5 years ago

Flash is a terrible example because there is literally no place for flash apps to go except be rewritten from scratch in some entirely different platform. Python 2 programs simply get ported to python 3. And we are already ten years into python 3, so yes, python 2 is going away at least as much as say Perl 4 or MySQL 3 or Oracle 7 has gone away. Which is pretty damn away.

Also they aren't withdrawing pip from being available for python 2. You just use the older version of pip. Programs that need pips newer features won't install on python 2 anyway. Because it's really going away very quickly now.

ianhanschen10• 5 years ago

It’s the closest example I could think of to draw on.

This is a good example of what I was talking about. Python 2.x isn’t “going away very quickly now.”

maxerickson3• 5 years ago

It's a fair bet that AIR will be supported until Ruffle gets fleshed out (Harman is taking it over).

(AIR isn't an interesting solution for a big chunk of apps, but there's lots where moving out of the browser is fine)

IlliOnato• 5 years ago

AFAIK even the most modern Perl 5.32 runs Perl 4 programs just fine, so "porting" programs from 4 to 5 was "trivial" in the strongest sense.

Perl 7 finally is going to break this compatibility, at least according to the current plan, but the "porting" still is supposed to be trivial, in most cases just adding a pragma or two. 27 years after Perl 5 was released...

macksd• 5 years ago

I've definitely worked on projects where people want to just have it working and leave it working until after I'm long gone. I've had clients that I'm sure are still on Java 6, CentOS 5, maybe older, and will be for years to come.

But the Python communities I've interacted with seem to care deeply about the ecosystem, updated libraries, new features. Web apps, data science, etc. Is my experience here warped? Are there people here seeing Python get used for the kind of stuff that might live as long as Cobol without moving forward with the language?

gbear605• 5 years ago

I think the largest chunk of Python usage is what you’re talking about. But there’s still a significant number of people (and importantly, companies) just using it as a scripting language to move around and parse data or files. They’ve gotta do it with something after all, so why not Python. And like other people were saying, these are the types of scripts that don’t get updated.

mplanchard• 5 years ago

One of the companies I used to work at had a several million line python 2 codebase supporting their product stack. They have decided to stick with python 2 at least for the foreseeable future, because the work of porting to python 3 is seen as too expensive and risky. This is a company that sold for over $2 billion to a much larger, much more enterprisey company. I wouldn’t be even remotely surprised if they’re still on python 2 in another ten years.

bcrosby95• 5 years ago

For future projects, sure. For ongoing ones, maybe. For projects that are working I'm not touching... why?

A tool is a tool. When I bought a new drill I used it to put together the playhouse for my kids rather than tearing down my fence just so I could put it back together.

lima• 5 years ago

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.

More likely, enterprise vendors like Red Hat will maintain Python 2 + pip for a long time.

The upstream project has no reason to do so and made the right decision to stop supporting legacy stuff.

x1798DE• 5 years ago

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.

dmart3• 5 years ago

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.

mumblemumble3• 5 years ago

It's just a new software release. If you still need pip 20.3.4, it's right here: https://pypi.org/project/pip/20.3.4/

dmart3• 5 years ago

Sure, but there are plenty of things out there that are just pulling the latest version by default (in our case it was the Vagrant ansible_local provisioner...)

haram_masala• 5 years ago

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.

asaddhamani• 5 years ago

Don't fix what ain't broke? If there's a legacy application using Python 2 and its working just fine, why upgrade?

knicknic• 5 years ago

Potential security vulnerabilities? If I have a library and it works in 2 & 3. But I stopped working on keeping it 2 compliant because 2 is no longer supported. Than I will never bring a single fix to 2, even security fixes. Due to code divergence it may not be even easy for me to understand if the issue reproduces in 2.

ianhanschen10• 5 years ago

You assume they will move forward, when they most likely won’t. It’s not a tax, it’s a product targeted at a guaranteed line of revenue. If 3.x were ever deprecated, they would start charging for that version. There probably aren’t enough users for their 3.x version yet, so it’s free to try and gain adoption.

mikekhusid• 5 years ago

Do you have any examples of this? Not doubting it, just curious.

imhoguy• 5 years ago

That is quite interesting OSS funding method - charge for legacy patches and support which no-one else would provide. Although it is likely boring venture, but that is the price.

hjek• 5 years ago

charge for legacy patches

Oracle are doing that with Java too.

Too3• 5 years ago

Similar to how we dealt with IE6 back in the days. By default not supported, any time spent on workarounds for IE6 are billed double hourly rate, and mind you these often require a lot of time.

Quickly made a lot of our clients untick the IE6 requirement from the wishlist.

ChuckMcM• 5 years ago

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.

icegreentea24• 5 years ago

`pip` is still going to work - all the weird mistakes are going to keep happening. `pip` is just no longer providing new clients for 2.7 - existing clients will keep working.

tim333• 5 years ago

Thanks. As someone with python 2 code I was worrying. No probs typing pip2 install if 3 is default.

oconnor663• 5 years ago

I think a lot of important lessons got learned in both cases. Clearly perl6 should have had a different name. But I think python2->python3 could've been much less painful if they'd known to prioritize single-codebase compatibility from the very beginning. I think you can see that lesson applied with e.g. Rust editions, which as far as I can tell have been a complete success.

xmprt• 5 years ago

Single codebase compatibility meaning that you can have python2 and python3 code in the same application? Isn't that significantly harder with an interpreted language or am I missing something?

Blikkentrekker21• 5 years ago

Hindsight might very well be easy in this case, but I cannot think otherwise than finding the Python developers to have been ridiculously naïve in how they handled this, and foolish to even begin it from the start.

The minor improvements of Python 3 did not warrant breaking backwards compatibility and most could have been handled in a way that would not break it opt-in directives.

The very swarms of users that chanted “just upgrade” as if that not incur a significant cost also seemed ridiculously naïve to me, not understanding the real cost that large projects have by having to rewrite very extensive codebases and dealing the potential regressions that that might involve.

Everything about the switch, from it's very conception, to it's execution, was handled in a veritably disastrous way by the team, that really did not seem to appreciate even a fraction of what obviously is involved with projects that have millions of lines of code and of course would rather not have to rewrite that all.

This is why many projects such as Linux, Windows, Rust, Cobol, Fortran, C, and C++ take backwards compatibility quite serious. Serious enterprises do not like to invest in something if it mean that 10 years later they would have to rewrite their entire codebase again.

Even on my home computer, I simply do not have the time to rewrite the many Python 2 scripts that have written over the years that run my computer. — it is cumbersome enough that once in a while part of my desktop stops functioning because my distribution removed a Python 2 library which I had relied upon as a system library that I now have to install as a user library but that was hitherto quite easily fixed.

Do these men think that time is free?

pjmlp12• 5 years ago

I am still not sold to Rust editions and think in the long run they won't be much different from solutions in other platforms.

There will come the day when something will change semantics, or require different kinds of runtime support across editions, and then the headaches how to link binary crates from different editions will start.

Editions to me appear only to work, provided everything is compiled from source code with the same compiler, aware of all editions that came into use.

Donckele• 5 years ago

“Rust editions, which as far as I can tell have been a complete success.”

Can anyone tell me why statements such as these get the emotions going?

simias• 5 years ago

Rust editions, which as far as I can tell have been a complete success.

Rust's commitment to backward compatibility is certainly extremely commendable, but I don't think the language went through anything resembling the switch from Python 2 to Python 3 in terms of breakage.

Some of the changes in Python 3 are very fundamental. Imagine if Rust had shipped without String/str and they were added after the fact, would Rust manage to avoid splitting the ecosystem? That's an open question as far as I'm concerned.

And I also hope that we never find out. Rust's fundamentals have proven to be very solid so far. Having things like OsStrings (something missing from most programming languages, including Python 3 AFAIK) shows a great amount of foresight and understanding of the problem space. Contrast that with Go which seems very intent on completely ignoring 30 years of programming language evolution.

linspace• 5 years ago

I hear very often criticism of Python's transition but considering how insanely popular the language has grown I don't understand why.

dragonwriter4• 5 years ago

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

This won't change that at all; pip/pip3 is a distro packaging thing, and any distro that packages legacy python2 as “python" and Python 3 as “python3” will probably continue packaging legacy pip-for-python2 as “pip” and pip-for-python3 as “pip3”.

uranusjr3• 5 years ago

Most likely, some will rename the command and some will not, causing more pain for everyone :(

jasonjayr• 5 years ago

For the record, Perl6 has been officially renamed to Raku[1]

IIRC the language known as "Perl", version 5, when it gets to the point when it is going to update it's major version, will skip 6 and go right to Perl 7

1: https://lwn.net/Articles/802329/

ptero• 5 years ago

Yes, but it took so many years of confusing people not deeply familiar with the situation that perl6 will be a better perl5 (as perl5 was a better perl4, perl4 was a better perl3, etc.) while in reality it was a very different beast.

LeoPanthera• 5 years ago

This is why you always type “python3 -m pip” instead, to avoid ambiguity.

antpls3• 5 years ago

Renaming to a complete different name is not necessary, everyone understands a major version breaks compatibility. Python3 is still very close to Python2 both in syntax and spirit.

But there was a sort of broken promise given by the Python creators: Python3 was almost like Python2, but every library author had to review and repackage their libraries, anyway.

At that point, Python 3 should have been unambiguously incompatible with Python 2 :

  - the only allowed file extension should be py3

  - all environment variables should have been duplicated with a "3" (it shouldn't read or modify Python 2 env vars)

  - all installation folders should have been duplicated with "3"

  - all tools like pip should be suffixed with "3"

  - and most importantly, it shouldn't try to  optimistically run previous Python2 code or previous v2 tools

The mistake was that you could use "pip" or "python" in bash scripts/shell, and not know if python2 or python3 were going to run.

Still today, you can run "python" in a recent version of Ubuntu or Fedora, and it will be Python 3. Only "python3" should be possible. Distro are repeating the same mistake than with Python 2, and we will struggle again with Python 4, if there is any Python 4.

Many headaches wouldn't have happened if "python" was reserved to Python 2.

Pro tip to language and distro maintainers : make the major version part of the language name and executable, from version 1.

masklinn3• 5 years ago

- the only allowed file extension should be py3

That would have made cross-version codebases impossible, and that's what ultimately allowed migrating. One-shot migrations were not convenient, or successful, or even effectively feasible for complex enough projects.

What allowed the migration was community experiment in cross-version sources, as well as reintroduction of "compatibility" features into Python 3.

sedatk• 5 years ago

everyone understands a major version breaks compatibility

That's not the case with C# or Java.

jart2• 5 years ago

Why try to imagine the way it should have worked, when it shouldn't have happened in the first place. Python 3 was invented because Guido felt it looked nice, and the economic value of all the labor that went into pleasing him is likely equal to that of a small country.

feanaro• 5 years ago

There's a certain cognitive overhead and ugliness to having to run `tool3` instead of `tool`, which makes me dislike this solution.

alerighi2• 5 years ago

That is not an elegant solution. That way you would forever had 3 in the name, even for future version of Python (e.g. python4, that will not break compatibility with old source code and thus making a .py4 wouldn't make sense).

In your shell you don't run "java8" or "java11", you just run "java", and then it's the matter of what version of java JDK you have in your PATH. The same with all other language interpreters and compilers, you don't run gcc9 or node14. Why doing something different for python?

Really, the mistake of python3 was to break compatibility with past programs. A lot of changes could have been done more gradually, in the first version require a __future__ import, then gradually remove compatibility with old features, and then remove them completely, making the new way the default and thus no longer require the __future__ import. And I think it will be the way for next python version, so in theory we will never have the same problem again.

Also to me it was an error for distros to continue packaging python2 as python. Other distributions, like ArchLinux, switched everything to python3 as default a lot of time ago, it's only Ubuntu that continued to ship python2 as python, thus making a lot of programmers relying on it. It would make sense that the command without the name refers to the latest version, and not the legacy one.

oaiey• 5 years ago

Regarding rename the framework: It did and did not work with .NET Framework and .NET Core. There is a lot of issues still there (and their branding decision now is to go ahead with ".NET" ... Which is also not good).

However, I do not disagree. Renaming is the right thing. A version number is easily omitted.

lucideer3• 5 years ago

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.

Perl and Python are the only two examples of this to my knowledge: most open source languages do fine introducing breaking changes in major versions.

The question is why Perl and Python had such problems while for example NodeJS, PHP (comparable webserver scripting languages) have had no such issues.

I wonder is it anything to do with the areas they're used in (Python & Perl are popular local/cli scripting languages in addition to web—has Bash had similar version woes?), or is it purely that the changes they made were more significantly breaking than others'? That's probably true of Perl6/Raku at least.

kekeblom2• 5 years ago

Likely a key factor is leaving support for the old version. If they had immediately deprecated python 2, users would have quickly updated their packages over to a supported version.

zbuf2• 5 years ago

In some fields, Python is embedded as an interpreter into major binary platforms or commercial apps.

So in many of these cases the end user doesn't have a choice to use Python 3 until it's on offer.

And the vendor has usually integrated Python at a binary level into C code; that's why they provide a Python API.

The answer could even be "Red Hat Enterprise Linux 6"; consider that Python 2 is the default in this OS, which ended official support only at the end of last year. Many enterprises _chose_ this platform for its longevity, along with 3rd party vendors of commercial software.

Macha• 5 years ago

Node 0.12, Java 6 and 8, PHP 4 - there's been plenty of examples of "sticky" versions in the past that had to be pushed away for other languages

wheresmycraisin8• 5 years ago

Perl never had a problem (at least with the Perl 5 and Perl 6 distinction) besides marketing. No one has ever been confused why their perl script doesn't work because their perl was version 6 instead of 5, and they never will be. No one has ever had worry about having writing a perl program to be compatible with both, unlike python where you never know if "/usr/bin/python" is 2 or 3.

merb2• 5 years ago

PHP had, never heard of php6?

EamonnMR10• 5 years ago

A better comparison would be to Typescript which is a breaking change from JS but is branded differently. I'd love native typescript in the browser but browser vendors aren't going to go pushing a massive breaking change like that.

globular-toast2• 5 years ago

The pip/pip3 thing is partly the fault of distros and partly due to lazy training and insufficient tooling for python.

The only distro I'm aware of which tries to protect users shooting themselves in the foot with pip is Gentoo. Most of the others will happily let you "sudo pip install" stuff and lead people to think that's the correct way to do things.

Unfortunately pipx has come too late. Pipx provides a real way for users to install arbitrary python tools, but too many docs out there tell users to use pip. Then you've got all the users who want to "play around" with python and install libraries. Even things like jupyter have crap support for virtualenvs and make it far too easy for users to have all their projects in a single env. It's a mess.

Regular users should never have been exposed to pip2/pip3. They should never have even been interacting with the OS python interpreter. Pip should only exist in a "global" contexy to support bootstrapping virtualenvs and nothing else. Poetry does a lot of this right.

skohan3• 5 years ago

Python is the best example I can point to for how important it is to get the versioning and dependent management story right.

Python is one of the most "accessible" languages in terms of the actually programming experience, but making a project reproducible is a nightmare. There doesn't seem to be a real "right way" to manage dependencies, and getting a project running seems to often start with figuring out how the author decided to encapsulate or virtualize the environment their project is running in, since changing your system python for one project can break another.

I know it's an older language, so many lessons have been learned, but after working with Rust, or even NPM it seems amazing that developers tolerate this situation.

xyproto2• 5 years ago

A dedicated docker container per python project "solves" this issue, but it's a hacky workaround, not a solution.

ghshephard2• 5 years ago

Re: Dependencies - There are at least two well known, well supported, rock solid ways of managing dependencies that are in very common use in the python deployment world.

Some combination of requirements.txt (which lets you dial in, with great precision, each of the libraries you need, and is trivially created in < 50msec with "pip freeze")

1. Containers - That's it. You control everything in it. 2. virtualenv - Every environment comes their own version of python and their own set of packages and versions of those packages. Add virtualenvwrappers and you can create/switch trivially between them.

It's been at least 2 years since I've run into a issue with python and dependencies that wasn't solved by both of those approaches.

scrollaway• 5 years ago

Forget containers. The actual "right" way to manage python dependencies in a project is Poetry. It's very solid and super reliable and uses virtualenvs internally.

Pipenv could have been it but it never got far.

cheph• 5 years ago

open source languages have to put up with this

Not sure what any of this has to do with open source languages, mind clarifying?

pornel• 5 years ago

OTOH PHP managed to migrate 4→5→7, and knew when to back out of v6. JS managed to migrate to ES6.

I think Python's failure is unique. It needlessly broke too much back-compat at once, provided too little benefits to make up for it, and let everyone drag their feet for a decade with the upgrade.

wheresmycraisin8• 5 years ago

Also guaranteed that there will never be a Python 4 or any way to innovate the language.

pyrale4• 5 years ago

JS managed to migrate to ES6.

"We have nearly endless money and therefore we can make any new feature by treating older versions of our langage as bytecode and write transpilers for it".

wheresmycraisin8• 5 years ago

Perl 6 was never meant to 'kill' perl 5. It's a completely separate language, has been from the beginning, and it's been renamed Raku recently. Unlike with python, perl devs realized even 20 years ago people realized there was too much legacy perl 5 code for 'replacement' to be practical. The result is that perl 5 is very backwards compatible, Raku is at the very least an interesting language worthy of some attention.

Compare this to Python 2/3. It's basically an incompatible fork that doesn't add enough for many projects to consider upgrades, and adds the overhead of having to worry about two version. All it really accomplished was guarantee that "Python 4" will never, EVER be a thing.

pvg3• 5 years ago

The more accurate thing would be to say it ended up killing all perl, which is something the Python 2/3 transition hasn't done to Python, warts an all.

lizmat3• 5 years ago

Perl 6 *was* to be the next version of Perl. That was the intent when the whole effort started in 2000. That it didn't turn out that way, has many causes. Enough has been said about that already. But to say that it was a completely separate language from the beginning, is historically incorrect in my opinion.

EamonnMR10• 5 years ago

They should have called the new language python.encode("utf-8").

appleflaxen2• 5 years ago

omg yes. this needs to become the gospel. by renaming you lose "branding" that you quickly regain, and don't affect compatibility at all.

if you step back and think about it, using the same word for two fundamentally irreconcilable things is mad.

amelius• 5 years ago

This still won't free us from the "your pip version is out of date" errors.

jshen• 5 years ago

Ruby did it right.

appleflaxen2• 5 years ago

what was their approach?

GNU_James4• 5 years ago

Why don't we have a single interpreter that can run both Python 2 and 3 code?

yedpodtrzitko• 5 years ago

How would that work? I assume you'd still need to declare which version you want to run as, and if any library you want to import wouldnt be compatible, then either you are where you are right now, or it would bring a lot of backward/forward incompatibility issues with unicode/bytes/strings/syntax etc.

nhumrich• 5 years ago

How would it know which version a file was supposed to use?

CamperBob2• 5 years ago

Same way a shell script specifies what interpreter to run, maybe? Meaning some form of standardized comment header.

ben509• 5 years ago

Because nobody wants it.

You probably could run GraalPython, which is Python 3 and Jython, which is 2.7, since they both run inside a JVM.[1]

There'd be no interop between the languages, though. To get that in Graal, you'd have to reimplement python 2 using Truffle.

That's a massive effort compared to simply running 2to3 to migrate your old code to Python 3.

[1] https://www.graalvm.org/reference-manual/python/Jython/

tclancy• 5 years ago

Why don’t we have a single interpreter that can run every language? And how come I can’t get no Tang round here?

kortex5• 5 years ago

You can, it's called use __future__, six, and 2/3 compatible idioms. I've been writing code (begrudgingly) like this for years. Test suite runs on 2.7-3.6 no problem, albeit annoying to write vs pure py3.

max_• 5 years ago

I am mostly a hobbyist dev, and the transition from Python 2 to 3 has been rather painful.

I have had to rewrite several projects, just so they could continue working.

But I understand the need fot it. So iam not bitter or anything

diragon• 5 years ago

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.

EamonnMR10• 5 years ago

As cool as Common lisp is, python fans are probably python syntax fans, or at least syntax fans.

kazinator• 5 years ago

I suspect most Python users simply don't know anything else. That's how they got introduced to programming, and unless someone holds their hand again, they will never use anything else.

Also, many devs who work in Python in fact hate it. Python is so popular, it's foisted onto people.

In some jobs, you have to interact with Python from time to time, even if you don't develop in it.

Udik• 5 years ago

So when's Python4 coming out?

EamonnMR10• 5 years ago

Drop single equals assignment in favor of walrus, actually enforce type hints where possible, loose the GIL, get rid of bytes.

kortex5• 5 years ago

Soooo...golang?

I write python kinda like go. So easy to debug and refactor. It's quite nice.

atoav2• 5 years ago

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.

It is so ironic that in Python the most "unpythonic" thing is the version management of the language and libraries etc itself.

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.

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

StavrosK2• 5 years ago

I think that currently the biggest nightmare when it comes to packaging is that installations are usually not self-contained. If you can create a virtualenv or run Poetry, your headaches are over and you'll have a very pleasant experience. I don't think I've ever had a problem running stuff with Poetry and the way it does locking.

All the problems come before that point, with multiple installations making it so you don't know which installation you're using, which version, etc.

mixmastamyk2• 5 years ago

Not sure what I’m doing “wrong,” but I have no nightmares packaging Python, it all just works. I suppose some ecosystems have done it better, but no complaints from me.

krzyk3• 5 years ago

I still can't get why they replaced: `print "abc"` with `print("abc")`.

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.

But I don't write production code in python, it is used only for small shell scripts, or like calculator.

HDevo• 5 years ago

For basic calculations, let me recommend bc to you: https://en.wikipedia.org/wiki/Bc_(programming_language)

This way you don't even have to type "print" ;)

krzyk3• 5 years ago

I don't need to type it in python also, unless I do some loops or functions.

I tried bc once and it was too big learning curve for just simple calc that indo in python.

tephra• 5 years ago

Having print as a function instead as a statement provides flexibility and ease of customizing.

Printing to anything but stdout, printing with a separator, using the end keyword, etc, all became easier.

Too3• 5 years ago

If you use the REPL as a calculator you don't even need print at all! The terminal will automatically print the result of your last statement!

    >>> 5+5
    10

krzyk3• 5 years ago

Yes I know that.

But look at my comment above, I use also for loops and functions.

mbar84• 5 years ago

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: https://github.com/mbarkhau/lib3to6

ema• 5 years ago

I wonder how many of the people taking issue with Python2 still being used are using miles and inches to talk about distances?

lrossi• 5 years ago

Or a certain temperature scale used in Liberia.

Andrew_nenakhov2• 5 years ago

The only thing I miss about Python 2 is print.

print "hello" > print("hello")

kortex5• 5 years ago

I never understood this logic. It's two characters, and it's a pain to port once you go from print statements to actual logging. Also coming from C I'm used to print functions.

Andrew_nenakhov2• 5 years ago

Python code with this absence of begin/end {} block statements is easy to read and looks beautiful. This additional () in print takes away some part of that beauty.

lillesvin• 5 years ago

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.

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.

gigatexal• 5 years ago

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.

PaulHoule3• 5 years ago

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.

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.

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.

IgorPartola2• 5 years ago

You are partially right. Distros like Debian/Ubuntu used Python 2 extensively as a system dependency and so replacing /use/bin/python became a big undertaking. But since at least 2009 it was easily possible to install alternative versions and use them with virtualenv. pyenv has made it even easier since then and it made it platform agnostic.

PaulHoule3• 5 years ago

I use virtualenv all the time, its great.

Yet no matter how much I try to educate users some of them still feel entitled to use the system Python and I find it disheartening to try to suppport those people.

svnpenn• 5 years ago

That's why I never put System32 on my PATH. nothing really worthwhile in there, and it just causes problems like this.

PaulHoule3• 5 years ago

In the last 2 years or so Win 10 has gotten aggressive about restoring configuration changes (e.g. the fruits of all that telemetry research.)

I have found that my PATH entry reverted at least once after I tried to hide the system Python and I am also wonder if Microsoft will use their 'monkey patch the standard library' approach to forclose any stopping the insanity.

easton2• 5 years ago

It’s not even in System32, it’s in %localappdata%\WindowsApps. Which is also where other appx packages you install put their PATH shortcuts. Upside is, you can disable the behavior (by binary) in Settings, but then you have to hope that isn’t overridden next time someone needs to bump up their Python download numbers.

Aissen2• 5 years ago

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.

globular-toast2• 5 years ago

Why can't you ship your own interpreter to the machine? It's a mistake to ship python source code out to some distro maintained interpreter. Think of your interpreter, dependencies and source code as one atomic unit.

Aissen2• 5 years ago

You can, of course, think of it this way; and you probably should. But, it also means more work, and you might as well update your distro if you go down that path. I'm reluctant to build & ship my own python for a very simple reason: you then take on the role&responsibilities of the distribution maintainers. I've taken over these roles in the past, and I recognize that this is hard, thankless work. You have to weight whether or not you can do better than the major distributions (you probably can't), and if it's even worth your time.

Spiritus2• 5 years ago

Probably because Python 3.5 was EOL’d last year and 3.4 two years ago.

https://endoflife.date/python

avian• 5 years ago

Python 3.5 is the latest you can get on Debian Stretch (oldstable) from official repositories. Stretch is still in the Long Term Support program until around 2022. Dropping support for Python 3.5 means you can't use latest pip on Stretch anymore.

punnerud• 5 years ago

Then I finally can stop typing “python3 -m pip install ...”

blhack3• 5 years ago

This thread is depressing. It seems like so many of us are happy to build an incredibly fragile world.

hannasanarion2• 5 years ago

This was announced 13 years ago. That's enough time to get an entire computer science doctorate and write your own alternative package manager from scratch, if you really need it so much.

If Pip dropping py2 support today kills your app, it wasn't fragile, you were negligent.

blhack3• 5 years ago

Who are the people that are creating a fragile world here? The ones who didn’t rewrite their code to be compatible with the existing software called python, or the ones who didn’t rewrite their code to be compatible with the existing software that uses python?

I don’t have any rights to python. If I chose not to rewrite my code for python3, I am increasing the fragility of the world.

However the same is true for the python maintainers. If the maintainers were interested in maximum anti-fragility, Python3 should have been a fork.

I’m not making any sort of moral judgement here. But I think it’s obvious both from the actions of devs not rewriting their software, and python being willing to make breaking changes, and that everybody seems to be blaming each other (and have been for a decade), that the goal here wasn’t really to create long lasting tools.

willis9368• 5 years ago

C code written 50 years ago is not EOL. Why is it acceptable that all code written in a specific language 15 years ago needs revisiting?

ausjke• 5 years ago

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.

let python be python3, and python2 for python2 instead

Too3• 5 years ago

Clean Ubuntu 20 install does not do this. It is because you apt installed python-is-python2. Maybe some other package included it as dependency.

btw there is also a python-is-python3 package.

I would advice you to not use either of them, use virtualenv, pyenv or poetry instead.

dkdbejwi383• 5 years ago

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?

shadow28• 5 years ago

Think pipenv is becoming the de facto standard for package management. https://realpython.com/pipenv-guide/

nerdponx4• 5 years ago

It is popular, but it is not standard by any means. There are many voices against it in the Python community who prefer Poetry, or who have stuck with setuptools because there is no mature replacement yet.

easton2• 5 years ago

Is pipenv still being patched? When I moved to Poetry, I did because there were outstanding issues for pipenv that made it bug out with my setup (pretty sure it was a WSL thing?) but the maintainer hadn’t committed anything in months and wasn’t accepting PRs.

Poetry has been solid, at least lately.

yhoiseth• 5 years ago

I’ve tried a few, and my favourite combination is pyenv-virtualenv and pip-tools.

ForHackernews2• 5 years ago

Poetry is very good https://python-poetry.org/ better than pipenv in my experience.

madsbuch• 5 years ago

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.

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.

carapace5• 5 years ago

FWIW...

How long will PyPy support Python2?
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.

https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s...

Narann• 5 years ago

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 years despite its ubiquitous usage make me realize it's no more an industry driving domain.

Pip has dropped support for Python 2

Related Stories