Wow! Wish the majority of packages i encounter has this problem; too many releases.

That sounds really nice. Actively maintained packages for a change.

Have successfully installed py315 pyenv install 3.15.0

Which packages currently support py315

pyenv please do what you do so can start testing py315

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.

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.

• pretty format YAML

• 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)

• uv and ruff

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

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.