24 ms·

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 sai

• 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.
      • uranusjr 6y ago
        “Pidgin Python” is such an apt term, why am I only seeing it when it is no longer relevant!
      • dwheeler 6y ago
        That's the main working solution I found: code works in both versions. The problem is that it's way trickier than it should be. Has they made that relatively easy, the Python 2->3 transition would have had a much smoother "normal" upgrade process.
    • deleted 6y ago
      [deleted]
    • slaymaker1907 6y ago
      It's a mostly solved problem with Racket. What they probably should have done was have python 2 code somehow declare itself as python 2 (Racket does this with #lang at the top of files). Then, just have a python 2 compatibility layer that works in two steps. First step is to compile/parse it into a similar form as python 3. Additionally, provide a small python 2 runtime which provides different versions of the functions which changed from 2 to 3. I think the two steps are important because some stuff is easier to solve via compilation like "print" while other stuff may be only possible at runtime like strings being unicode. You would still have some differences which can't be papered over, but it would have made writing code that works in both python 2 and 3 much easier.
  • Blikkentrekker 6y ago
    Hindsight might very well be easy in this case, but I cannot think otherwise than finding the Python developers to have been ridiculously naï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 naï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?
    • brodie 6y ago
      The Python core devs did not have the time or motivation to support the old codepaths in the CPython runtime, and the legacy code was getting in the way of a lot of longtime wants and needs for improving performance, runtime maintainability, language ergonomics, and the standard library. They also specifically increased the major revision number to signal their intent to move on from that legacy. But you kind of addressed your entire spiel: Hindsight is exceedingly easy. They didn't realize how inadequate their migration tooling was, or how very entrenched Python 2 is in various places. It's hard when you don't know what you don't know and you're highly motivated by hopeful aspirations.
      • 6y ago
  • pjmlp 6y 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.
    • johncolanduoni 6y ago
      There's no ABI compatibility between different Rust compiler versions as it is, so I don't see how editions will break a compatibility that doesn't exist.
      • pjmlp 6y ago
        Which is my point about it being half solution.
    • fluffything 6y ago
      You keep repeating FUD. Read the damn Editions RFC. The community agreed that no semantics or ABi breaking changes will land to Rust, EVER. This is not a lesson from Py th on, but from C++, which introduces breaking changes every single release, which are much smaller than Python but still a pain in million LOc code bases. If that ever happens, it was agreed that the result would be a different language, with a different name. That is, editions don’t have this problem because the FUD that you are trying to spread every single time this issue comes up cannot happen, by design. Your argument “Rust editions don’t solve this problem because they don’t handle semantic or ABI changes” is false, because in Rust there CANNOT be any semantics or ABI changes, and editions handle this situation just fine. In the context of Python 2 vs 3 this argument makes even less sense, because editions allows combining libraries from different editions ina forward and backward compatible way without issues. Source: work on multiple >500kLOC Rust code base and one >1 million LOC and they all use crates from all editions, and mix & match them, without any issues, doing LTO across them, using dynamic libraries, and all possible combinations of binaries across 4 major platforms.
  • Donckele 6y 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?
    • richardfey 6y ago
      Hello AI!
      • sgt 6y ago
        Hello AI!
  • simias 6y 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.
    • stjohnswarts 6y ago
      Well they had a lot of languages to look at and say "ummm that didn't work out for them so well, let's not do that" such as the Python fiasco.
  • linspace 6y ago
    I hear very often criticism of Python's transition but considering how insanely popular the language has grown I don't understand why.
    • EamonnMR 6y ago
      Python2 was poised to take over the world and be the next Java. 3 is losing ground to Node, Go, Rust, even Lua. 3 is a really fun and productive language to work in as long as you don't need to think about bytes.
      • paulryanrogers 6y ago
        My guess is Python wouldn't have done much better anyway. The GIL and lack of client side support kept it out of a lot of use cases.
        • Demiurge 6y ago
          Really? I’ve been using Python for 15 years and never heard anyone say “GIL”. How and what is GIL preventing?
          • paulryanrogers 6y ago
            https://wiki.python.org/moin/GlobalInterpreterLock https://wiki.python.org/moin/GlobalInterpreterLock
          • stjohnswarts 6y ago
            It causes issues with running low overhead multithreaded code. I get by with the multiprocessing library, but then again I don't have a lot of threads (10 is the most I've ever needed), some people want to run hundreds of "light threads" depending on the type of programming that you are looking to do.
    • stjohnswarts 6y ago
      Statistics and probability.
• dragonwriter 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 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”.
  • uranusjr 6y ago
    Most likely, some will rename the command and some will not, causing more pain for everyone :(
    • Anon1096 6y ago
      This is already the case. Arch has python for python 3 and python2 for python 2. It's the opposite on Ubuntu and most other distros.
      • pseudalopex 6y ago
        Arch is why there's a PEP saying not to do that.
        • deleted 6y ago
          [deleted]
        • Kwpolska 6y ago
          The PEP [0] has been revised since then, and the current recommendation regarding /usr/bin/python is "equivalent to python2 OR equivalent to python3 OR not available at all OR configurable by user/sysadmin". [0] https://www.python.org/dev/peps/pep-0394/ https://www.python.org/dev/peps/pep-0394/
      • cozzyd 6y ago
        On Fedora: $ python --version Python 3.9.1
      • 6y ago
• jasonjayr 6y 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/ https://lwn.net/Articles/802329/
  • ptero 6y 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.
    • wheresmycraisin 6y ago
      It would've taken 45 seconds of reading wikipedia article to figure out that Perl 5 and Perl 6 are different languages. Java went from 1.4 to 5. With standardized languages like C/C++/etc you have to keep track of not only the toolchain version but also the standard version (like C99/C++11, etc). Programmers routinely keep track of these just fine.
• LeoPanthera 6y ago
  This is why you always type “python3 -m pip” instead, to avoid ambiguity.
• antpls 6y 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.
  • masklinn 6y 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.
    • antpls 6y ago
      I dont buy this argument at all. Any sufficiently complex Python 2 project does not work with Python 3 without modification, there is _no_ cross-version compatibility. And if you wanted to try that yourself anyway, changing all .py to .py3 in a directory is one unix command... It could easily have been part of a 2to3 tool
• oaiey 6y 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.
• lucideer 6y 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.
  • kekeblom 6y 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.
    • carlhjerpe 6y ago
      Somehow it feels like PHP being a synonym to WordPress and Node going though babel makes these languages different too from perl and python too.
    • user5994461 6y ago
      >>> If they had immediately deprecated python 2, users would have quickly updated their packages over to a supported version. Painfully wrong. They tried to deprecate at least twice, it was so bad a decision that they had to backtrack. In fact Python 3 is the hard proof that you cannot hope users to upgrade, by abandoning ship and giving no way to upgrade.
      • kekeblom 6y ago
        Well there is a way to upgrade. They even provided an automated tool that would convert code and warn you about the handful of changes.
• globular-toast 6y 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.
• skohan 6y 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.
  • xyproto 6y ago
    A dedicated docker container per python project "solves" this issue, but it's a hacky workaround, not a solution.
    • wegs 6y ago
      There's a scene in Major Payne: === [Marine has been wounded] Marine Private: AHHHH my arm, my arm! Major Payne: Want me to show you a little trick to take your mind off that arm? [Marine nods and Payne grabs the private's pinky finger] Major Payne: Now you might feel a little pressure. [Major Payne breaks the Marine's pinky] Marine Private: AUGGGGH! My finger, my finger! Major Payne: Works every time. ==== That's kind of how I feel about Docker. Before, you had a problem. With Docker, you have a new, bigger problem (and most of your old problem hasn't gone away; it's just been masked for a while). (And yes, I know I'm in the minority here)
      • RyanHamilton 6y ago
        Snap! I feel the same seeing people use docker for dependency management. Now you have two problems.
        • wegs 6y ago
          On a more serious note, most uses of Docker that I've seen push problems back, and have accumulating technical debt (with interest). * Robust systems shouldn't be tied to pinned versions. If your code works with PostgreSQL 9.6.19, and doesn't work with 9.6.20 or 9.6.18, that's usually the sign of something going very, very wrong. * In particular, robust systems should always work with the latest versions of libraries. In most cases, they should work with stock versions of libraries too (whatever comes with Ubuntu LTS, Fedora, or similar). It's okay if you have one or two dependencies in a system beyond that, but if it's a messy web, that's a sign of something going very, very wrong. * Even if that's not happening, as much as I appreciate having decoupled, independent teams, your whole system should work with the same versions of tools and libraries. If one microservice only works with PostgreSQL 11.10, and another with 12.07, that's a sign of something having gone way off the rails. These aren't hard-and-fast rules -- exceptional circumstances come up (e.g. if you're porting Python 2->Python 3, everything might not land at the same time) -- but these should be rare enough to be individually approved (and usually NOT approved) by your chief architect/architecture council/CTO/however you structure this thing. For the most part, I've seen Docker act as an enabler of bad practices: * Each developer can have an identical install, so version dependencies creep in * Each team has their own container, and it's easy for versions and technologies to diverge * With per-team setups, you end up with an uncontrollable security perimeter, since you need to apply patches to a half-dozen different versions of the same library (or worse, libraries performing the same function) The docker/microservices/etc. mode of operating gives a huge short-term productivity boost, but I haven't actually seen a case on teams I've been on where the benefits outweigh the long-term costs. That's not to say they don't exist, but they're in the minority. For the most part, I use Python virtual environments and similar, but by the time you hit docker, I back away.
• cheph 6y 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 6y 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.
  • wheresmycraisin 6y ago
    Also guaranteed that there will never be a Python 4 or any way to innovate the language.
  • pyrale 6y 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".
• wheresmycraisin 6y 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.
  • pvg 6y 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.
    • wheresmycraisin 6y ago
      Go ahead and run "sudo rm /usr/bin/perl" on all your servers then and tell me what happens.
      • oblio 6y ago
        I'm reasonably sure a big distro recently removed Perl from the base install.
        • wheresmycraisin 6y ago
          Which one?
          • pvg 6y ago
            What difference could that make? There are lots of languages shipped in various distributions that are no longer 'living' languages in the sense that they have little mindshare and little new development is done in them. Perl wasn't one of those languages and now it is. If you want to comment on that or perhaps dispute it, sure. But the 'delete perl and see what happens' thing is beside-the-point nitpickery.
• EamonnMR 6y ago
  They should have called the new language python.encode("utf-8").
• draw_down 6y ago
  Yes, that’s right. It’s a different thing and should be called differently.
• appleflaxen 6y 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 6y ago
  This still won't free us from the "your pip version is out of date" errors.
• jshen 6y ago
  Ruby did it right.
  • appleflaxen 6y ago
    what was their approach?