371–380 of 513 posts
(I know someone who will pretend to know my situation better than I will advocate for some "solution;" no, it won't work in a way that won't break some of my priors)
Earlier quoted context omitted.
This is such an odd and entitled take for a person who is really trying hard not to care about python.
I prefer Hg over Git but I use Git. Why? One time I tried to use hg command and it didn't work. Why? I was on a system that had incompatible Python interpreter to the Hg scripts. That was it. Since then I use Git everywhere even though I prefer Hg.
Since then I only use Ed even though I prefer MS Office. What was your point again?
I like Python 3. It eliminated a whole category of encoding/decoding errors. Even Python 2 codebases benefited from it, as libraries were updated to handle Unicode better in an effort to achieve compatibility with Python 3. I didn't experience much pain migrating codebases to it, but I'm just speaking for myself here. Congratulations to Debian on upgrading to Python 3!
Earlier quoted context omitted.
This is totally false - code produced by 2to3 no longer ran on 2. So you ended up w a chicken and egg problem. Things like u would allow folks to keep compatibility with 2 while working in 3. Your comment is a perfect illustration of the issues. Lots of user blaming. No actual solution. As I said, it did start to get massively better at some point. Instead of condescending lectures on org issues they for example bega…
> This is totally false - code produced by 2to3 no longer ran on 2. That's what "breaking changes" and "backwards incompatible" means. What exactly is hard to grasp? > So you ended up w a chicken and egg problem. You really don't. Your code and your upstream dependencies need to be ported to python3. Once your dependencies are updated, all that's missing is you doing your job. Python2 has been on the path to deprecat…
This isn't strawmanning - this is literally the case for a codebase I'm working with today.
Earlier quoted context omitted.
Isn't that effectively what was done with Python? You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code. Rather than it being wrapped up in a single entry-point, you had the different runtimes and library sets.
> You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code .. but you can't use old libraries in new code.
As someone who does not use Python , the end result of this is that I now look into whether random utilities I use happen to be written in Python, and if so try to find an alternative. This is because I felt the pain of this transition -- again, as someone who does not program in Python. It has been miserable every time some random utility starts complaining that Python 3 is missing and then somehow when you install…
This rant feels like it would have been relevant in 2016-2018 or so, but in 2022-2023 I write a lot of Python code and don’t really run into Python 2 vs 3 issues anymore. Once Python 2 officially EOL’ed the ecosystem basically managed to port whatever was important enough to keep using over to Python 3. Im sure some legacy megacorps are still doing stuff in Python 2 but that’s no different from these corps running so…
I feel your response is best summarized as: "I like Python. I've never had this problem and don't think it's a legitimate problem. Only $megacorp users have this issue, and their concerns aren't important."
If you dismiss the problem (as you've done) then you don't have to intellectually address it. The Python 2 -> 3 transition was hard for those that huge productive workloads in Python2, and this pain will have a long tail.
Glad this is finally mostly over, but... that was bad. I wonder if the energy that had to be put into this migration by everyone involved was worth what seems to be relatively small improvements. The print-as-a-statement was ugly but convenient and didn't seem like a big deal, the integer division was something that you could live with once you knew about it (and you still need to know what the current behavior is),…
I don't understand why there apparently wasn't a clearly stated preference about `python` being Python 2 and `python3` being Python 3 from the Python org.
Earlier quoted context omitted.
>You have containers that have worked for years that all of a sudden error out saying "Python 2 is no longer supported," Isn't this precisely the problem containers are trying to solve? You can update your system, get rid of unsupported software, and still keep the older version of Debian within your container that depends on an unsupported version of Python.
That's the dream of containers. Arguably this is the "reality" of Nix. But the reality of containers is that if a layer gets invalidated, you need to refetch packages that are lower down. If the Python 2 versions (or Python 2 itself) is removed, then you can't "just" surgically make the change you want in the container without affecting the rest of the system (this is a major failing of Docker, but the world we live…
Earlier quoted context omitted.
> "Python 3.3: Trust Me, It's Better than 2.7" The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then…
> No, it's not even remotely worth the amount of confusion and work it caused. Have you worked with pervasively non-ASCII text in Python 2? Like on a machine where any file might suddenly turn out to be non-ASCII (even if it’s only in a comment), not just data inside a few carefully-patrolled fences? Outside of a few well-behaved libraries (Flask), my experience was that it was utterly impossible. More than half of m…