I think you just discovered software engineering, which at its best makes intelligent tradeoffs to optimise use of resources to meet needs.

i don't see a numpy equivalent in Javascript, and that's just the first module that came to mind that I know PyScript can run in the browser.

Monopolists never like it when their monopoly is threatened ... ;-)

As well they should be.

Oh, my God, I actually wrote some code in Fortran 2 back in 1969! It's certainly a much better language now!

I wouldn't say Python is good _at_ vectorization so much as good _with_ it. It's also good with AI, web systems, etc, as a result of its "play well with others" philosophy, which pragmatically accepted from the start that no one language could be best for all purposes.

One of the best improvements to Python's memory model was extending it to allow sensible access to blobs of memory containing regular structures such as vectors and matrices, making it relatively easy to interface with and control already-available, well-tried, highly-optimised algorithms.

Does it understand pytest, do you happen to know by any chance?

It does indeed.

It seems to understand the way you want your unit tests written. So if you have a particular style, it's best to write one or two tests in your style, then it will use that same style when it starts writing tests.

You can do prompts like "I need unit tests for the exceptions that are raised in the SuchAndSuch.function()", and it will do it -- particularly if you have a unit test already written similar to what you'd like.

Given the many ways of creating virtual environments it's becoming more usual for a program's installation to create a specialist virtual environment just to support that application (pre-commit is. good example of this technique). Perhaps that'a a way ahead?

This is almost mandatory if you want to ship something which might be considered "standalone" on Python.

It's quite ugly, and I try to make sure I write modules that can be built to a standard wheel and installed that way. (Poetry makes this fairly easy, incidentally.)

Doing development on the projects without a specialised build environment, though, is almost hopeless. You either have to manually install a bunch of stuff (e.g. I use ruff, used to use ruff and black, used pre-commit, and a few other things), and then there's the non-Python things that need to be installed (like specific fonts in my case). At this point I just impose Poetry as basically a requirement for development.

The program does build and function in a non-Poetry environment which is what I use for production.

They'll all co-exist. Add them all to your PATH, make one the default python3, and request specific versions when they are required.

I don't need the default, because which python to choose depends on project's dependencies which may work only for specific versions. And then you build a venv and it lives there. It's not some safety measure, it's a natural choice. I don't need bare `python` command outside of venv.

That said, 3.12 doesn't even have python312.exe in its folder. If 3.13 follows, having both of them in PATH is useless.

Well, this has all the signs of well-meaning but inexperienced developers seeing a market opportunity without appreciating the many difficult problems that will have to be solved to produce something that is secure, reliable and interoperable with current development ecosystems.

Rather than abuse them, we might perhaps use them as an example of the Dunning-Kruger effect.