Actually most of the LLMs algos are less efficient than the readable human one, even with only two nested loops. Only one of them precalculates the factors which makes the biggest difference (there are log2(N) factors, worst case, for large N and a triple loop over those is better than a double loop over 1..N).
I've used pypy on large codebases for years. Generally it's fine so long as you don't need any of the packages that are thin wrappers around C/fortran. It seems a lot of maintainers these days are pretty good about considering it as a target
On the other hand the memory footprint can be painful - not just the deferred garbage collection of things like weakrefs and closed files, but even regular objects. A while back I had hope that the faster cpython project would somewhat remove our need to use it, just so we could have a lower memory footprint, but that seems to have stalled
Speaking as somebody who has had to debug why servers were ignoring changes to the configs in our git repos, this is a welcome change.
It's a shame there are ways to bypass it, but at least it communicates the intent: you aren't supposed to modify this system without modifying the actual config
Very nice! We spent quite some time on this and aren't even having a kid.
How did you implement the tournament? It feels very long when you have many names - almost like it's doing all N^2 pairs, or is there something smarter?
Yes. I had pretty much this conversation a while back with some non-technically minded people who had been convinced that by creating an ontology and set of "semantic business rules" - a lot of the writing of actual code could be automated away, leaving the business team to just create rules in a language almost like English and have the machine execute those English-like rules.
I had to explain that they were basically on track to re-implementing COBOL.
We use pypy pretty extensively at our firm for analytics/olap work.
We've actually tried using some of the more traditional libs (Pandas et al) with CPython, but there's always a pure-python bottleneck (e.g. SQLAlchemy).
Performance is important to our clients and trying to keep everything performance critical in C extensions / NumPy would be kind of risky for us when adding new functionality, so pypy's guarantee of more speed pretty much across the board is awesome.
There are downsides of course - higher memory usage, longer boot times, some more obscure libraries being unsupported - but on the whole, it's a good choice for us