That would break every single module that is compliant with flask 3.x and imports it with `import flask`. This simply isn't justified by the "benefit" of some old packages not having to change a single line of code.
Yes, maybe in hindsight it would have been beneficial to put the major version of some packages (flask is far from the only one) directly into the package name, as a workaround for pythons inability to deal with multiple versions of the same module under the same name in one environment. But python works as it does, `import flask` is how god-knows how many projects use it, so that's how the show runs, period.
If some package requires a certain version, it can pin that version in its `setup.py`. If a project requires a certain version it can pin that version in it's `requirements.txt`. If an environment requires a certain version, the admin can create a virtualenv.
As Rich Hickey argues in the talk I referenced, semver and version pinning is a problem not a solution. I’ve written lots of code using only stable dependencies that are stable over the span of decades, and it’s just a much nicer ecosystem to be able to rely on.
> semver and version pinning is a problem not a solution
Almost every practice in software development is a compromise that wouldn't be necessary if some decision in the past were different.
I think I agreed with you somewhere in this thread, that version-names (flask1, flask2, ...) are a better solution than major versions.
However, `flask` as an import name isn't going to go away. That is simply a reality and we have to work with it, because alot of projects rely on this. The same is true for tens of thousands of important software packages all over the OSS landscape.
So we can argue all day and then some over "what if"s...it won't change the status quo that exists, and in that state, semver is a good compromise that solves way more problems than it introduces.
