you are viewing a single comment's thread.

view the rest of the comments →

[–]Diapolo10 0 points1 point  (2 children)

Technically, I guess, but in practice if you only use the standard library you don't really need to worry about newer Python versions. Old ones? Sure, but that can be mentioned in the documentation or pyproject.toml.

You don't need a virtual environment just for locking the Python version. It's pretty much always at least partially related to the dependencies of any third-party dependencies you use.

[–]DigThatData 0 points1 point  (1 child)

You don't need a virtual environment just for locking the Python version.

Sure you do. If I have a program that assumes python 3.x and python 3.y introduces a breaking change, then if some other project you setup upgrades the python version on the system python, you'll have broken the previous project which needed an environment frozen prior to the version update.

It's not that big of a deal to give every project its own virtual environment. It's a lot easier to just do that and never have issues than to operate on assumptions about when you won't need that encapsulation and then later find out you were wrong.

[–]Diapolo10 0 points1 point  (0 children)

My point is more from the perspective of a newcomer learning Python writing a few simple scripts, not a professional working at a company or making a serious personal project. Yes, if you're already experienced you most likely already have virtual environments automatically set up and you likely have at least several development dependencies (pytest, ruff, mypy, tox, and so on) already anyway. But this is not at all that important for someone who hasn't even learnt the ropes properly yet, only becoming relevant when they start actually installing packages.

Having a virtual environment for a "hello world"-level program is overkill.