3 ms·

Everytime I read an article about all these tools I really can't help but think what would happened if Linus would have taken over the desktop. All the tools re

Everytime I read an article about all these tools I really can't help but think what would happened if Linus would have taken over the desktop. All the tools really largely seem to try to poorly replicate Linux package management and the fact that because of this devs now don't care anymore about api stability and not always building against the latest and greatest. I admit a pyenv is nice for testing against different python versions if necessary. But on my Linux systems generally fine with just installing system packages and doing pip install --user for the odd package that is not in the repositories

mariokostelac 6y ago
I think that works when you use Python cli tools, but not when you're working on 5 different projects, each running different python version.
- Sohcahtoa82 6y ago
  Outside of Python 2/3 differences, are Python interpreters not backwards compatible? In other words, while obviously a program written for 3.3 won't work in 2.7, but will a program written for 3.3 fail to run in 3.8? If it runs fine, why the need for multiple interpreters? I'd think you'd get by just fine by having the latest 2.x and 3.x installed.
  - mariokostelac 6y ago
    It's just about backward compatibility. If you don't run the exact version of python that's running in production, how do you know that you're not using some method that does not exist in production yet (because you run older version there)? Also, libraries with binary component often have to be compiled against specific version of python.
  - a_cool_username 6y ago
    Sometimes! A very simple example is code that uses "async" as a variable name. It became a keyword in 3.5, which was an enormous pain in the ass.
  - Izkata 6y ago
    Because underscore-functions aren't truly private, I have once seen an upgrade from 2.7.8 to 2.7.13 fail. A commonly-used package was importing one from a core python module.

mariokostelac 6y ago

I think that works when you use Python cli tools, but not when you're working on 5 different projects, each running different python version.

Sohcahtoa82 6y ago
Outside of Python 2/3 differences, are Python interpreters not backwards compatible? In other words, while obviously a program written for 3.3 won't work in 2.7, but will a program written for 3.3 fail to run in 3.8? If it runs fine, why the need for multiple interpreters? I'd think you'd get by just fine by having the latest 2.x and 3.x installed.
- mariokostelac 6y ago
  It's just about backward compatibility. If you don't run the exact version of python that's running in production, how do you know that you're not using some method that does not exist in production yet (because you run older version there)? Also, libraries with binary component often have to be compiled against specific version of python.
- a_cool_username 6y ago
  Sometimes! A very simple example is code that uses "async" as a variable name. It became a keyword in 3.5, which was an enormous pain in the ass.
- Izkata 6y ago
  Because underscore-functions aren't truly private, I have once seen an upgrade from 2.7.8 to 2.7.13 fail. A commonly-used package was importing one from a core python module.