Thank you for introducing me to act. First time seeing it.

Static typing redundancy is a waste of compute.

Have never encountered anyone suggesting doing less static type checking.

Static typing finds bugs. Especially pyright. Especially within tests. Separating the static type checking into stubs reduces any performance impact from typing related imports.

With py315, there will be soft|lazy import. Excess imports will have minimal impact cuz import proxy will be created but not executed until the import is actually used..

Tox is only necessary if you want to validate across specific versions so it can be replaced by tools like Poetry.

No it can't. They are two different things. tox can be replaced with nox. In the past, nox was promoted in this community. Looked into it and couldn't, for the life of me, figure out how it added value?

You mentioned Poetry, so i get to belittle Poetry. If you hadn't mentioned it, Would have keep my mouth shut. So this is on you!

Poetry only reason for being is to bring all the requirements files into TOML. The author loves TOML format. I get it. But at the expense of removing the constraint and requirement files hierarchy. Or a sane way of dealing with requirements of multiple venv. Or a sane clean way of managing dependency imposed lowerbound pins. Which come and go, so need to attribute which dependency imposed which set of lowerbound pins and most importantly why! Over time, the why is lost and with all the pins imposed by from various now unknown dependencies mixed into one insane pot.

Poetry is fine if you are the author of one package (and live in a utopia and not clownworld or fight club). And you have one venv. Lets scale that up to being the prolific author or maintainer of 10 or 100 inter-dependent packages each package having multiple venv. Now you are good and fck'ed cuz Poetry doesn't handle that situation. In fact, nothing does.

wreck tracks requirements by venv and syncs all the requirements as best it can. My intention was to eventually sync across multiple packages. But never got around to writing that level.

Poetry is unnecessary from the day the author first sat down to write it. And is the source of frustration to end users cuz Poetry encourages author/maintainers to create dependency upperbound pins.

So tell me again how wonderful Poetry is. Go on defend it!

The pyproject.toml spec is ten years old. Python 3 is almost twenty years old.

To my knowledge, for TOML spec, strict validating against a schema is not a thing. So it's not used with very likely dangerous user input.

So the spec could be 100,000 years old, for obvious security vulnerability reasons, would still not touch it.

Recommend taking a read through the strictyaml authors documentation on shortcomings of various user supplied input file formats.

You are in for a treat:

• Why

• Why not

specifically Why not TOML

First thank you for taking a look and holding my feet to the fire.

Have several packages based on strictyaml. What matters is YAML files are validated against a schema. Whether use .yml or .yaml is personal preference. My personal preference is typing less characters. Both should be allowed.

Share your hatred of Windows and don't even see it as a serious OS. So was actually surprised that .yml has some association with Windows or MSFT.

If while using any of below packages, you find the .yaml suffix is not recognized, that would be a bug. In which case, create an issue.

These published packages could be affected:

logging-strict

pytest-logging-strict

sphinx-external-toc-strict

To actually confirm has bug status, would have to review the unit tests and see if .yaml is not tested nor recognized. Otherwise it's mere conjecture. It's an unconfirmed possibility. Maybe you are right, maybe not. Or maybe you are on to something.