no. No it wouldn’t. It would break 99.9999% of python interpreter version checks cuz we are all following the exact same patterns.
… the next day you’d be here saying that was a really bad idea.
Luckily people smarter than us already decided that was not worth pursuing. And we are better off for those folks with foresight instead of 100% clarity in hindsight.
Luckily people smarter than us realized code checking for versions couldn’t distinguish from 3.14 and 3.14blahblahblah
That idea sucks please forget you ever supported it and i’ll do the same. The point is now mote anyway.
The lead up to py315 is better than sex. Out with the py310 (2026-10-01) in with the py315 (2026-10-09)!
Waiting one more whole day is torture.
I get to be this excited for lazy imports
Can’t tell if made a convincing argument or sneezed without covering my nose.
The entire point of the argument was to convince others to deliberately not engage it. It being ruff.
A clearer comment might be, “yeah i love flake8, black, and isort. They are great or at least sufficient!”
ruff is Rust. I stay away from introducing Rust into Python tech stack. Since if something goes wrong, the burden of maintaining it falls upon user base all of which are not Rust experts. It’s a heavy burden.
Would recommend removing it.
What’s the ruff pitch? memory safety in a linter is about as important/useful as tits on a bull.
Been seeing most packages atm supporting py310 - py314. Other abandoned packages just have py3+ which is good enough.
The issue is when you go full async native and drop sync codebases. Then no choice but to step up and help maintain other AWOL author/maintainers projects.
Glad to be helpful. Did you try out interrogate and typos?
There is no way for xyz to be either included or excluded from a package cuz everyone should be running python -m build and checking the tarball and .whl before even considering a commit or a release.
So although the OP chose hitch that doesn’t change the workflow of manually checking the tarball.
I use setuptools, wreck (requirements management), and drain-swamp (choose versioning by either “tag” or “current” rather than specifying exact semantic version). What i use has no bearing on the opinion above.
“modern” means you are a little bitch. I’m very tired of that term. A function with multiple return statements is considered “modern”. Whereas i see that as wrong. So now that “modern” word is being thrown around for packaging?! Please stop using that term. It’s a cope for not being able to code your own build backend (drain-swamp), frame stack free locals inspection (logging-strict), and requirements management (wreck)!
Use whatever you are familiar with without peer pressuring others.
py310 … nah … bah … chigau … passu … sochi ga ii
stubtest (static vs runtime)
rather than
pyrefly coverage check (static only)
So pyrefly is a bean counter. If using mypyc, e.g. black, doesn’t have stubs, then understandable this could be a valid use case.
BUT that is an outlier. Without stubs that removes the usefulness of pyright which catches actual bugs.
static vs runtime matters
Similarly to how test coverage measures how much of a library’s source code is hit by its tests, type coverage measures what percentage of a library’s typables have type annotations.
Errrr no!
type coverage should be how much of the typing has corresponding tests. This is particularly important for stub packages. Which are focused on confirming the advertised typing accurately reflects actual typing.
Hope they didn’t cyber squat the package name.
Listen to Yoda, “Try? Either do or do not! No try there is.”
The correct answer to percentage of a libraries typables having type annotations is either zero or all. This is advertised by the py.typed file. There is no middle ground.
Wtf is wrong with pyrefly authors?
Stub package with naming starting with type- does not follow PEP561.
The convention is types-*.
So yeah, what is type-coverage?!
Tools i recommend:
rebuff – finds places in code to replace with better algorithms. Wanted a tool to recommend itertools and itertools-more usage, but achieve that. Chosen cuz it’s not Rust.
typos – fixes typos in both code and docs
mypy+pyright+stubtest – need all of them. pyright phones home. mypy isn’t enough it misses way too much.
cyclonedx-bom – create software bill of materials
pip-licenses – NOTICE.txt and licenses.json Answers question does my toolchain include virus licensed packages?
interrogate – Any code documentation missing? Does not enforce documentation quality.
wreck – sync requirements files; otherwise it’s tedious (i’m the author)
If it can be helped, don’t want Rust nor nodejs in my toolchain. Recommending to Python coders who are very likely not Rust or node.js experts is malpractice or unethical (call it what you may). If you had a problem with any non-Python packages would be at the mercy of non-Python communities. i’m struggling just with Python community black issue 2514 now you want us to broaden that struggle?
And if people are too dumb or lazy to learn how requirement file hierarchies work, perhaps they shouldn’t be Python coders.
Disclosure: author of wreck
Dependabot got annoying. For logging-strict git repo, turned off dependency graph. Blindly updating mostly nodejs crap is insane, it’s a supply chain attack waiting to happen.
Disclosure: author of logging-strict
The OP mentioned dealing with user input via pydantic. Which acts schema-like. strictyaml does the same for YAML config files where runtime validated against a schema.
And here is why all the other config file formats are dodgy, why-not written by author of strictyaml (not me).
Disclosure: Author of types-strictyaml, logging-strict, pytest-logging-strict, and sphinx-external-toc-strict. So yes i drank the kool-aid, but welcome challenges to preference for YAML config file format over others.
Don’t want individual dependency packages listed within pyproject.toml. Breaks the hierarchical nature of requirements files.
There is only so much enshitification my eyes can endure.
I’m the author of wreck.
lazy imports – ftw!
built-in sentinel – finally
I’m confused once py315 comes out why to stick with any previous version. As author of multiple packages, why would wait for several years before getting the benefits of lazy imports? This is not a rhetorical question, i’m requesting feedback why would you continue to wait?
This point is not clear to me.
Remember back in the day … raw SQL. All the children in unison say, “Woah”!
There is no avoiding the database part: model module, alembic migrations, static type checking, UDF, UDF rtyping, string PRAGMAs/SET|SHOW. And a beautiful config file to link them all!
Database work is very time consuming.
have to reevaluate if async is that important to me or not.
Why would be concerning yourself about that? Should have both [a]sync support throughout. Discussing this shouldn’t even be a topic it should be the norm.
pyenv please do what you do so can start testing py315