34 ms·

Pip has dropped support for Python 2

• hprotagonist 6y ago
  A nearly 13 month grace period beyond EOL seems quite generous to me.
  • dwheeler 6y ago
    Usually yes. But almost all language transitions are easier than the Python 2->3 transition.
    • hprotagonist 6y ago
      a decade's worth of grace period, on the other hand, is probably too generous.
      • dwheeler 6y ago
        Not at all. It's only too generous if there is a low-cost way to incrementally transition to 3, as is normally the case with language updates. Python 2->3 was a poorly managed update that did not follow normal upgrade rules, so the "normal" rules don't apply. It is still often very extremely expensive to convert python2 to python3. Normally you could upgrade in small steps, maybe a file or library at a time, instead of changing everything simultaneously including all transitive dependencies. That problem continues to be denied, so python2 continues to be used. I say that as someone who has converted code from 2 to 3. Python3 is fine, it's the huge unnecessary transition cost that is not. It's gotten a little better, but not a lot better. This makes it worse. Now it's even harder to incrementally update, making it even harder to switch to 3.
        • michaelmrose 6y ago
          If you started only making new stuff in python 3 in 2010 2 years after python 3 came out how much python 2 would you have to convert? If of course you spent an extra decade producing obvious technical debt whose fault is it?
          • pishpash 6y ago
            What about code people wrote before 2010 that were perfectly fine? Are you going to have people rewrite research algorithms whose original authors have long graduated? Just because industry has a habit of rewriting the whole stack every five years on account of make-work job security doesn't make foundational scientific algorithms change.
            • philderbeast 6y ago
              if the code still has value being run in modern environments, then it probably needs to be maintained and updated anyway. if its not being used, then does it running with the latest tools even matter?
              • lanstin 6y ago
                Not really. For example R ships with or depends on a lot of FORTRAN libraries. I doubt they have changed much at all in decades. There is no talk of a breaking FORTRAN language change that would require rewriting this perfectly FB ctional code with a stable interface.
            • michaelmrose 6y ago
              Couldn't you isolate the entire outdated environment this 2002-2009 code is expected to run in? Plenty of code written in this time frame is liable to depend on unsupported things by that point.
            • bastawhiz 6y ago
              Except the Python folks produced tools that did almost all of the work for you. 2to3 has worked for an overwhelming number of use cases. And in fact, most code requires very few changes to begin with. If this academic code isn't well understood or well tested, it's probably not as valuable as you might think.
              • dwheeler 6y ago
                > 2to3 has worked for an overwhelming number of use cases. And in fact, most code requires very few changes to begin with. That is not at all my experience, nor is that experience of most other people I've ever talked to.
        • joshuamorton 6y ago
          > Normally you could upgrade in small steps, maybe a file or library at a time, instead of changing everything simultaneously including all transitive dependencies. This was absolutely possible. Via the path of upgrading your code (or your dependencies code, in any arbitrary order) to be compatible with both py2 and py3 (via, say, six) and then once all code was compatible in either direction, flipping the switch.
          • fennecfoxen 6y ago
            It was always dangerously hard to validate that the whole codebase was actually compatible, and there wasn’t some path through the code that would make things break (in production on the customers’ site while handling all their most critical data). I can think of exactly one language who bungled the upgrade path worse and it’s Perl 6, which they finally renamed after 19 years of stringing people along like it would be the next big thing.
            • joshuamorton 6y ago
              I generally agree with your statement (the version flip is scary), but that's a different complaint than GGPs, which was more that you couldn't incrementally migrate your source files. The version flip to Java N+1 can be scary and cause issues too (and sure, it's perhaps less likely to cause issues, but don't worry, they both do!)
        • tgsovlerkhgsel 6y ago
          The main issue I ran into was string handling. Autoconversion handled most of the rest, but because byte-strings and regular strings were interchangeable in Py2, random places that weren't even touched by the autoconversion now suddenly have a "b'abc'" where they should have "abc", and fail in very non-obvious ways. Just some hack around that would probably already help.
          • eesmith 6y ago
            I had to change my public APIs in a backwards-incompatible way. I had a method something like obj.to_string("abc") to convert the object into a string in 'abc' format. I also supported things like obj.to_string("abc.gz") to get the record in gzip-compressed form. I also had a from_string() -> obj functions. You can see the problem. I had to change to_string() so it didn't allow compression (breaking backwards compatibility) and add a to_bytes() for that functionality, and add type dispatching in the from_string() code to support either byte or strings, with different code paths. And change all the open() calls to use "b", and to add type checks on user-passed-in file objects to insist on reading bytes (if not isinstance(user_file.read(0), bytes) raise "Must be open in binary mode") because all of the underlying parsers are in C and the needless decode/encode step adds overhead. Oh, and re-write the C extension so it handles both Python 2 and Python 3. That was a really boring 6 weeks.
      • ed25519FUUU 6y ago
        Have you stopped to ask why the transition was so bad?
    • smitty1e 6y ago
      Whereas the Perl 5.8 upgrade pretty much killed the language.
    • mumblemumble 6y 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.
      • MattGaiser 6y ago
        A friend of mine uses Python in his lab. Tons of them were writing Python 2 code when they were learning it two years ago (Feb 2019). So they started from scratch with it two years ago.
      • josefx 6y ago
        > the main source of difficulty in Python 2->3 is all the foot-dragging in migrating to Python 3. My main difficulty was having targets that ran python 2 and wouldn't get an official python 3 package unless a miracle happened. Meanwhile most systems supporting python 3 also had a python 2 package. Ended up porting a few scripts to a statically linked c++ binary, those should keep on working until we get 128 bit systems that drop support for 64 bit binaries.
        • busterarm 6y ago
          You learned an important lesson about distributing software and business risk. In my experiences trying to deploy software at scale (10^4~5), statically linked binaries are the only acceptable form of software.
          • yjftsjthsd-h 6y ago
            If you don't have a pipeline to update those static binaries, you're just giving yourself a different form of headache 5 years from now when you need to apply bug fix.
            • lanstin 6y ago
              With static linking you mostly have all the pieces updatable independently. Can move to new distro and keep the binaries. Can update some binaries with a bug fix to some parser library without releasing other binaries. Etc. except for glibc and stuff like 64-bit inode values.
    • philderbeast 6y 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.
      • pishpash 6y ago
        Academia doesn't have unlimited budget to do migrations that don't solve any pressing problems. I guess now there is a pressing problem, but more likely people will maintain the old version of pip locally.
        • philderbeast 6y ago
          Then they are asking the wrong question, instead of asking do I have to upgrade, they need to be asking why shouldn't I upgrade. Keeping current with industry is the only way they can stay relevant in the modern world, particularly in IT and related fields where anyone with a computer at home can do the same research as someone at a university.
        • meekrohprocess 6y ago
          Yeah, really. Graduate students aren't cheap! Oh wait, we pay computing grad students literally 1/10 of their potential salary ($10Ks vs $100Ks). Why could there possibly be a shortage? -_- More importantly, it shouldn't be prohibitively expensive to port academic Python code.
          • Wowfunhappy 6y ago
            Graduate students are there to do research, not update old existing codebases. That's a part of the bargain, part in parcel with the low pay.
            • Kalium 6y ago
              From limited exposure, these codebases are often in truly awful shape. They've endured years or decades of having been hacked up just enough to finish someone's thesis or dissertation with no concern at all towards maintenance. It should be no surprise that such a poorly engineered process produces awful results.
    • melling 6y 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 https://news.ycombinator.com/item?id=7372913
      • Wowfunhappy 6y ago
        Or, everyone leaves your platform because they can't keep up with the breaking changes.
        • adamc 6y ago
          Less a problem with languages, in my experience, than libraries. Django updates are a pain in the rear.
          • deleted 6y ago
            [deleted]
          • Wowfunhappy 6y ago
            idk. I think there's an alternate universe somewhere in which Python just got hard forked by the community, and the python foundation lost its influence over the direction of the language. The split today would be even larger, or Python 3 would have become an intellectual curiosity rarely used in the real world.
      • adamc 6y ago
        There isn't really a good solution. Forced migrations always create a decision point, at which point people may gather their resentments and move to something else. But if you don't eventually force a change, you have to live with all of the language's historical mistakes. My shop was interested in migrating long ago, but we had to wait until languages and frameworks (such as Django) supported 3. On projects where that wasn't a risk, we moved to Python around 2014 or so. But: I totally get that for some shops, the feasibility of migrating was low.
  • aidenn0 6y 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.
    • hprotagonist 6y ago
      right! pip 20.x will support py2 for ever!
    • mrweasel 6y ago
      Couldn’t you just fix it?
    • atoav 6y 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 6y ago
      That script is 17 years old, and will probably continue working for a while. It's not bad support for a free language.
  • adamc 6y 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 6y 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 6y 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 6y ago
  Good riddance! The fact that we're still supporting Python 2 at all in 2021 is madness.
  • GNU_James 6y ago
    Friendly reminder that entire scientific community runs on Python 2 legacy code and nobody will rewrite it to Python 3.
    • jennyyang 6y ago
      At some point it will be selectively rewritten if it's important enough.
      • awakeasleep 6y ago
        I love/hate this type of tautological yet provoking statement
        • ironmagma 6y ago
          In what sense is it tautological? I can think of a lot of things that are important that won’t get done, healthcare improvements being one. Software on the other hand is typically fluid enough that someone will rewrite it.
          • ozzy6009 6y ago
            If it wasn't selectively rewritten, it wasn't important enough (to be selectively rewritten).
          • kortilla 6y ago
            Because the bar can be effectively slid around justifying that it was/wasn’t important enough if it does/doesn’t get rewritten. It’s as meaningless as telling someone they will achieve their dream if they want it bad enough.
• erichocean 6y ago
  Looks like Pip 20.0 will have a long life…
• at_a_remove 6y ago
  I couldn't get pip to work with my stock install of Python that came with my, ah, daily driver.
• dleslie 6y 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.
  • icegreentea2 6y ago
    Old pip will continue to work just fine without dockerizing or VMing.
• GNU_James 6y ago
  Them Professors will continue to use their Python 2 tools until they die and they will use these tools for work and teaching. No silly nerds will tell them that from now on their tools need to get taken away from them because "muh progress". If it works, don't fix it.
  • yudlejoza 6y ago
    Seriously. If I expressed my opinions on the regressive attitude Python 2 lovers have shown in the last 13 years, I'd break this website's code of conduct.
    • GNU_James 6y ago
      I work at the University. This is the reality. You keep computers working without updates till they stop working and backups are lost.
      • dmitryminkovsky 6y ago
        That's one way to do it. I wish people would embrace the idea that an ecosystem moving forward does not mean that you need to move forward. It creates so much needless pressure in people's minds. In the absence of security considerations, updating software might actually be considered harmful.
        • GNU_James 6y ago
          They usually have some software created by some students in the 2000's. These people took their degrees and left years ago. Nobody will get paid to migrate this software and you can't get a degree for working on rewriting code. That's it. I was making backups of floppy diskettes last month with some obscure software. Windows XP is still king in many places because no drivers for ancient scientific hardware on Windows10 and Linux is "black magic".
          • dmitryminkovsky 6y ago
• cable2600 6y 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 6y ago
    Python 4.0 is not coming out, the next release is 3.10
  • GNU_James 6y ago
    Do we really need "progress" in software that just werks?
    • bolangi 6y ago
      Some people want Unicode support.
      • EamonnMR 6y ago
        Somehow Ruby manages to support unicode without requiring .encode and .decode everywhere.
  • wvenable 6y 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 6y 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-windows-7-8-10/ https://itman.in/en/how-to-install-visualbasic-6-ide-on-wind...
• Ceezy 6y ago
  Common are they suppose to support python 1? Every languages has breaking change at some point. People needs to move on.
  • userbinator 6y 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.
    • uranusjr 6y ago
      It was not, although they are indeed considerably less different from 2 to 3 and easier to migrate.
  • Blikkentrekker 6y 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.
    • pjmlp 6y ago
      They do, but you are yet to find one example in the mainstream languages that never did at least one breaking change.
      • tgv 6y ago
        Is Go mainstream enough? They haven't made any breaking changes so far. Which brings me to another point: not all breaking changes are equal. Sometimes, a change to a syntactic element is needed. But if there's an identical replacement for it, and it can be updated mechanically, there shouldn't be a problem (in theory). Making constructions or the standard library do things (subtly) differently without a fall-back to the original functionality is a much bigger problem: then you have to inspect every occurrence and verify if it still works under all conditions.
• qwerty456127 6y 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 6y 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.
    • dataflow 6y 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.
    • eesmith 6y ago
      https://github.com/python/cpython/commit/b71c7dc9ddd6997be49ed6aaabf99a067e2c0388 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 :'-(
      • corradoverh 6y ago
        :(
• Abishek_Muthian 6y 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 https://github.com/ccrisan/motioneye
  • agucova 6y 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 https://github.com/ccrisan/motioneye/pull/1978
    • Abishek_Muthian 6y 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 https://github.com/ccrisan/motioneye/pull/1572
  • rnestler 6y ago
    According to the contribution graph (https://github.com/ccrisan/motioneye/graphs/contributors 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 6y ago
  Just started a new app using Python 2.7.19. Is switching to 3 worth it?
  • Xavdidtheshadow 6y 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 6y ago
    Yes. Python2 will get harder and harder to maintain as a dependency. You're fighting the whole ecosystem at this point.
  • tkuraku 6y ago
    Python 2 is end of life. Python 3 should be the only option for new projects. Python 3 is great.
  • detaro 6y ago
    Yes, starting something new in 2.x really doesn't make sense anymore outside very very special circumstances.
  • loeg 6y ago
    If you're considering switching languages, maybe consider other options outside the Python family as well.
  • xxpor 6y ago
    I'll go further than the other commenters: starting a brand new project in python 2 at this point is engineering malpractice.
    • willis936 6y ago
      As is starting a project in python 3.
  • philderbeast 6y ago
• at_a_remove 6y 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.
  • mumblemumble 6y 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_remove 6y 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.
      • stqism 6y ago
        At my current company we’re in an awkward situation with python 2.7.1 and 2.7.5, I’ve found that a easy solution to circular dependencies caused by the new resolver is installing pip==20.2.4 and an older setuptools (I don’t have this version memorized) before doing anything.
  • 6y ago
• ianhanschen 6y 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.
  • Wowfunhappy 6y 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?
    • ianhanschen 6y ago
      If history tells us anything, the forcing function will come in the form of lots of noise once deployments begin to break.
    • dmitryminkovsky 6y ago
      I don't understand: why can't people just use the last version of Pip that supports Python 2?
      • 6y ago
• x1798DE 6y 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.
• dmart 6y 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.
  • mumblemumble 6y 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/ https://pypi.org/project/pip/20.3.4/
    • dmart 6y 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...)
      • icegreentea2 6y ago
        I'm curious how that happened? Does `python2 -m pip install -U pip` result in a broken install?
        • dmart 6y ago
          Vagrant does a `curl | python` of the "get-pip.py" bootstrap script. There's a GitHub issue about it here: https://github.com/pypa/pip/issues/9500 https://github.com/pypa/pip/issues/9500
      • deleted 6y ago
        [deleted]
• haram_masala 6y 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 6y 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 6y 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.
      • ianhanschen 6y ago
        That creates a good business model for someone to come along and charge a premium to fix security bugs in old code. I think it’s more likely something like that will happen, than everyone moving their code to work on 3.x.
        • Skgqie1 6y ago
          Although quite different, this made me think of how COBOL is largely in maintenance at many places, but pays premium rates for developers.
          • nerdponx 6y ago
            There have been several threads on COBOL here on this forum, and the anecdotal consensus is that COBOL developers don't actually get paid much more than developers in any other language.
• ChuckMcM 6y 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.
  • icegreentea2 6y 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 6y ago
      Thanks. As someone with python 2 code I was worrying. No probs typing pip2 install if 3 is default.
  • oconnor663 6y 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 6y 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?
      • gdwatson 6y ago
        Single-codebase compatibility means that the same code can run under both Python 2 and Python 3. The initial expectation was that translation tools would solve this problem, but it didn’t really work out that way. Adding language features and library shims to make it possible to write pidgin Python that would run under either version meant that you could migrate libraries and parts of large codebases one at a time until the whole thing ran under Python 3.
• GNU_James 6y ago
  Why don't we have a single interpreter that can run both Python 2 and 3 code?
  • yedpodtrzitko 6y 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 6y ago
    How would it know which version a file was supposed to use?
    • CamperBob2 6y ago
      Same way a shell script specifies what interpreter to run, maybe? Meaning some form of standardized comment header.
      • EamonnMR 6y ago
        In that case you wouldn't need a compatible interpreter, you'd just specify the interpreter you want in the shebang. Python does not usually use shebangs because you're supposed to run in a virtualenv, not shebang your files to your system python.
  • ben509 6y 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/ https://www.graalvm.org/reference-manual/python/Jython/
  • 6y ago
• max_ 6y 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 6y 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.
  • EamonnMR 6y ago
    As cool as Common lisp is, python fans are probably python syntax fans, or at least syntax fans.
    • kazinator 6y 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.
• bambam24 6y ago
  One more reason not to use java and python. Just use nodejs
• Udik 6y ago
  So when's Python4 coming out?
  • EamonnMR 6y ago
    Drop single equals assignment in favor of walrus, actually enforce type hints where possible, loose the GIL, get rid of bytes.
    • kortex 6y ago
      Soooo...golang? I write python kinda like go. So easy to debug and refactor. It's quite nice.
      • EamonnMR 6y ago
        I like that type hinting isn't mandatory, I don't like that it's unenforced. Gdscript is an example of a python-influenced language that does it right.
• atoav 6y 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
  • StavrosK 6y 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.
    • mixmastamyk 6y 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.
      • StavrosK 6y ago
        Are you on Linux? People with Macs and Windows seem to be having more problems, because on Linux there's usually one canonical Python installation, whereas on Mac you usually have one from brew, one from Apple, maybe one you downloaded from the site, and whenever you try to install things it's a gamble which Python was used.
        • mixmastamyk 6y ago
          Yes, Linux. Also, I know how to use a shebang, which command, install to user, and/or pythonX.Y -m ... to avoid problems. Perhaps newbies don’t get enough of that advice? I try my stuff on macos without issue, but perhaps not there enough to have big problems.
• krzyk 6y 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 6y ago
    For basic calculations, let me recommend bc to you: https://en.wikipedia.org/wiki/Bc_(programming_language) https://en.wikipedia.org/wiki/Bc_(programming_language) This way you don't even have to type "print" ;)
    • krzyk 6y 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 6y 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.
  • Too 6y 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
    • krzyk 6y ago
      Yes I know that. But look at my comment above, I use also for loops and functions.
• mbar84 6y 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 https://github.com/mbarkhau/lib3to6
• ema 6y 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 6y ago
    Or a certain temperature scale used in Liberia.
• Andrew_nenakhov 6y ago
  The only thing I miss about Python 2 is print. print "hello" > print("hello")
  • kortex 6y 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_nenakhov 6y 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 6y 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 6y 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.
• PaulHoule 6y 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.
  • IgorPartola 6y 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.
    • PaulHoule 6y 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.
      • einpoklum 6y ago
        I wonder if it would have helped to move the executable from /usr/bin/python to /usr/sbin/python . Or /usr/sbin/python-for-distro-use-only-dont-run-apps-with-this ...
        • anon19087 6y ago
          This is precisely what they did in RHEL 8: /usr/libexec/platform-python
      • IgorPartola 6y ago
        It would be nice if virtualenv type of functionality was just a first class citizen for Python. Basically if you could just specify the root of your project and have ./site-packages/ automatically included in the path or similar. Yes of course you can just update sys.path but it would be neat to do that with no code necessary. Or do it with a config file like how PlatformIO does library management.
• Aissen 6y 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-toast 6y 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.
    • Aissen 6y 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.
  • Spiritus 6y ago
    Probably because Python 3.5 was EOL’d last year and 3.4 two years ago. https://endoflife.date/python https://endoflife.date/python
    • avian 6y 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.
      • Spiritus 6y ago
• punnerud 6y ago
  Then I finally can stop typing “python3 -m pip install ...”
• deleted 6y ago
  [deleted]
• blhack 6y ago
  This thread is depressing. It seems like so many of us are happy to build an incredibly fragile world.
  • hannasanarion 6y 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.
    • blhack 6y 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.
    • willis936 6y 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?
      • ForHackernews 6y ago
        Good luck getting 50 year old C code to compile on a modern system. I'm sure it's theoretically possible, but then, so is continuing to use Python 2.
      • 6y ago
• ausjke 6y 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
  • Too 6y 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 6y 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 6y ago
    Think pipenv is becoming the de facto standard for package management. https://realpython.com/pipenv-guide/ https://realpython.com/pipenv-guide/
    • nerdponx 6y 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.
    • easton 6y 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 6y ago
    I’ve tried a few, and my favourite combination is pyenv-virtualenv and pip-tools.
  • ForHackernews 6y ago
    Poetry is very good https://python-poetry.org/ https://python-poetry.org/ better than pipenv in my experience.
• madsbuch 6y 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.
• carapace 6y 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-support-python2 https://doc.pypy.org/en/latest/faq.html#how-long-will-pypy-s...
• Narann 6y 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.