This is the conventional wisdom these days, and a real thing, but unless you are admin challenged, running your local scripts with the system Python is fine. Been doing it two decades plus now. Yes, make a venv for each work project.
If you're just writing tiny scripts for yourself, sure use the system Python. If you're doing work on a large Python app for production software, then using system Python isn't going to cut it.
This is a restatement of my post with a restriction to tiny scripts. I don't restrict myself to _tiny_ scripts, some of my libraries are substantial.
Keeping the number of dependencies reasonable is probably the most important factor, rather than lines of code.
I'm pretty sure that significantly more people were burned by fork being the default with no actual benefit to their code, whether because of the deadlocks etc that it triggers in multithreaded non-fork-aware code, or because their code wouldn't work correctly on other platform. Keeping it there as an option that one can explicitly enable for those few cases where it's actually useful and with full understanding of c…
I agree that fork was an awful default. However, changing the default silently just means people's code is going to change behaviour between versions, or silently break if someone with an older version runs their code. At this point, it's probably better to just require people give an explicit choice (they can even make one of the choice names be 'default' or something, to make life easy for people who don't really c…
I'm with you on undesirability of silent change of behavior. But requiring people to make an explicit choice would immediately break a lot more code, because now all the (far more numerous) instances of code that genuinely doesn't care one way or another won't run at all without changes - and note that for packages, this also breaks anyone depending on them, requiring a fix that is not even in their code. So it's downsides either way, and which one is more disruptive to the ecosystem depends on the proportion of code affected in different ways. I assume that they did look at existing Python code out in the wild to get at least an eyeball estimate of that when making the decision.
disclaimer: I don't work on big codebases. Pylance with pyright[0] while developing (with strict mode) and mypy[1] with pre-commit and CI. Previously, I had to rely on pyright in pre-commit and CI for a while because mypy didn’t support PEP 695 until its 1.11 release in July. [0] -- https://github.com/microsoft/pyright [1] -- https://github.com/python/mypy
I would tend to rely on a single tool, do you see advantages to use both?
Do you happen to have discrepancies between both? (e.g. an error raised by one and not the other)
disclaimer: I don't work on big codebases. Pylance with pyright[0] while developing (with strict mode) and mypy[1] with pre-commit and CI. Previously, I had to rely on pyright in pre-commit and CI for a while because mypy didn’t support PEP 695 until its 1.11 release in July. [0] -- https://github.com/microsoft/pyright [1] -- https://github.com/python/mypy
I would tend to rely on a single tool, do you see advantages to use both? Do you happen to have discrepancies between both? (e.g. an error raised by one and not the other)
I prefer mypy but sometimes pyright supports new PEPs before mypy, so if you like experimenting with cutting-edge python, you may have to switch time to time.
Beartype is incredible. It is soo fast I put it as decorator on all functions of all my projects. It's day and night compared to typeguard. Also the dev is... Completely out of this world
I don't get the point of a runtime type checker. It adds a lot of noise with those decorators everywhere and you need to call each section of the code to get full coverage, meaning 100% test coverage. At that point just use rust, or am I missing something?
Adding the decorator on top of every def takes max 5s in any good IDE so I really don't get why changing the language would be worth it.
And anyway beartype has a mechanism to run a hook once and it will automagically decorate all functions.