The thing is python3 IS a better language. Unicode is very important for me, as i deal with a multitude of languages. For a good comparison, see how PHP failed unicode with PHP6 and we still deal with an insanity that is the mb_ functions. In python this is a non issue, and its a very nice language to work with.
Why Is the Migration to Python 3 Taking So Long?
271–280 of 355 posts
Re: Why Is the Migration to Python 3 Taking So Long?
#272Earlier quoted context omitted.
> This is backwards thinking. And the alternative is cargo cult "newer is better". > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...
> On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java... Common Lisp has a backwards compatibility which goes into decades, and implementations like SBCL had no difficulties at all to absorb Unicode. Racket even supports different language standards and completely different languages (such as Scheme and Algol) running on the s…
> It is, however, a huge problem for domains like scientific computing, where most code has no maintainers and even for very important code there is no budget or staff for maintenance:
Data science is doing just fine, in fact is leading the migration: https://www.jetbrains.com/research/python-developers-survey-...
Re: Why Is the Migration to Python 3 Taking So Long?
#273In my current job, I can point out something that might be a contributing factor: I work in an industry where there is basically one 800lb gorilla of a vendor. They update rarely, because their product is a mission-critical, life-or-death sort of thing. Their current product is heavily, heavily integrated with x.y.z version of software from a different vendor in a different segment, but also weighing in at 800lb. Yes…
Surprised it's including pip, if it's really this old or tightly coupled, it's common to not have pip at all, or the old pip version simply can't run. If it can help you. The trick I use is to install a normal python 2.7 interpreter with pip. Then you can use it to install software to any directory, including the one from the other application. There are flags to specify what to install, from where to where, internet…
I came across a system where pip had broken the other day. easy_install to the rescue!
Re: Why Is the Migration to Python 3 Taking So Long?
#274Earlier quoted context omitted.
This is backwards thinking. Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. If someone wanted other than the core Python team wants to step up and maintain Python 2, they are free to do so, it's open source. But failing that, expecting the Python team to support the older/ less functional version of the code indefi…
> Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. No maintaining 2 versions of python is much cheaper, it's only being done in one place compared to the thousands and thousands of python 2 code bases you'd have to convert. It also only needs bug fixes, there are plenty of people/organisations out there that would b…
That's only true if you ignore all packages on PyPi.
It's extremely hard to keep compatibility with Python 2, many authors can't wait to do the support next year, many already dropped.
Re: Why Is the Migration to Python 3 Taking So Long?
#275Earlier quoted context omitted.
That's not a python thing- that most likely has to do with your package manager. In my archlinux installation, python resolves to 3, and I have to use python2 if I want 2
Well, PEP 394 suggested it be this way, so Python is also a bit complicit.
As the history section of that PEP notes, it was actually written in part as a response to distributions like Arch changing the default Python to Python3. Although it's true that the PEP originally said that python should point to Python2 (it doesn't any more), it also said that code requiring a specific version of Python shouldn't assume anything about the system default Python, instead using either python2 or python3 - and requests that distributors of Python provide these commands.
This suggestion was adopted by nearly everyone, including Arch Linux. If you're writing a script that calls Python, you probably still want python3 as your command for compatibility across all current distributions.
In other words, the intention of the PEP was not to ingrain Python 2 as the "default" Python, it was to get people to stop making assumptions about what Python version they would get and use the python2 and python3 commands instead. I do agree that it has had that effect.
Re: Why Is the Migration to Python 3 Taking So Long?
#276Earlier quoted context omitted.
> Unicode support was actually an anti-feature for most existing code. If you're writing a simple script you prefer 'garbage-in, garbage-out' unicode rather than scattering casts everywhere to watch it randomly explode when an invalid byte sneaks in. If you did have a big user-facing application that cared about unicode, then the conversion was incredibly painful for you because you were a real user of the old style.…
> Actually that's the behavior of python 2, it works fine, until you send invalid characters then it blows up. Not always. As far as I can tell writing garbage bytes to various APIs works fine unless they explicitly try to handle encoding issues. First time I noticed encoding issues in my code was when writing an xml structure failed on windows, all because of an umlaut in an error message I couldn't care less about.…
So you don't have to deal with it until user data includes _any non-ascii character_ (including emoji, weird spaces copied from other stuff, or loan words like café)
"Dealing with unicode" is really just about dealing with it at the input/output boundaries (and even then libraries handle it most of the time). But without the clear delineation that Python 3 provides, when you _do_ hit some issue you probably insert a "fix" in the wrong space. Leading to the classic Py2 "I just call decode 1000 times on the same string because I've lost track"
Re: Why Is the Migration to Python 3 Taking So Long?
#277Because there's been not enough carrot and too much stick. The only real killer feature of Python3 is the async programming model. Unfortunately, the standard library version is numbingly complex. (Curio is far easier to follow, but doesn't appear to have a future.) On the down side, switching to Unicode strings is a major hurdle. It mostly "just works", but when it doesn't, it can be difficult to see what's going on…
- format strings
- mandatory keyword arguments
- multi-dict splatting
- nicer yield semantics for generators
- Fixing system-specific encoding ambiguities
- dataclasses
- inline type annotations
- better metaclass support
- more introspection tooling
- pathlib (for nicer path handling)
- mocking pulled into the standard library in a cleaner way
- stable ABIs for extensions
- secrets handling
- ellipsis instead of pass (yeah who cares but I care)
- lots of standard lib API cleanup
All of this is very helpful for making clean applications. But I would say it's _very_ helpful for making good libraries as well. This stuff is about having a strong language foundation to avoid plain weirdness like the click issue .
Obviously it doesn't kill all of them, but there used to be even more of that kind of thing all the time. Library issues would basically get exported to its users, all basically due to language problems.
Re: Why Is the Migration to Python 3 Taking So Long?
#278Earlier quoted context omitted.
> This is backwards thinking. And the alternative is cargo cult "newer is better". > Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. On the other hand, they could progressively enhance upon a backwards compatible single 2 version. JS manages to do that just fine, as does Java...
Almost everyone hates both Java and Javascript.
Ah yes, let's turn this into a good old "your language sucks" thread
Re: Why Is the Migration to Python 3 Taking So Long?
#279Earlier quoted context omitted.
> Yes, it's expensive to upgrade from Python 2 to Python 3, but it's also expensive for the Python project to maintain 2 versions of Python indefinitely. No maintaining 2 versions of python is much cheaper, it's only being done in one place compared to the thousands and thousands of python 2 code bases you'd have to convert. It also only needs bug fixes, there are plenty of people/organisations out there that would b…
That's only true if you ignore all packages on PyPi. It's extremely hard to keep compatibility with Python 2, many authors can't wait to do the support next year, many already dropped.
> That's only true if you ignore all packages on PyPi.
Presumably any packages worth maintaining will have far more dependent projects, so it's still far less overall effort.
> It's extremely hard to keep compatibility with Python 2
So don't? I don't think most of the people dragging their feet on the upgrade need or even want new features. A stable python 2 branch with bug fixes and security patches would suffice for most and be ideal for many. Over time the bug fixes should trend to zero and there probably aren't a heap of security issues in python projects anyway.