btown

The billion-dollar question is: what things might an LLM see as a bug or candidate for simplification, but supported a unique use case? https://xkcd.com/1172/ as always is prescient.

The thing about "rewrite X in two weeks" - or an entire company's worth of code in 24 months - is that it gives scarcely little time to do incremental rollouts to limit splash radius, or to identify and gather stakeholders to whom one can ask "why was this necessary" (or who can be guided to mine their emails and chat logs for conversations about the same).

Which is not to say this shouldn't be done! Let AI-native people guide the momentum with all the fervency of a hungry founder... but find project leaders who are committed to the empathy towards those who depend on the quirks of their workflows - ones who will create "curiosity loops" that try to bring in stakeholders as rapidly as possible on material questions, not just "continue, follow what you think is best" loops when the LLM brings up an open business question.

And sure, you can encrypt at rest, and perhaps even enforce that only re-encrypted versions are ever seen by the management/API web server. But fundamentally this display requirement means that if your management/API web server is compromised, users' secrets can be obtained by a process of impersonation.

For clarity, the Mistral model license is here: https://huggingface.co/mistralai/Mistral-Large-4-1T-A52B/raw...

> 2. If the Licensee or any of its affiliates operates a Model as a Service business, the Licensee must enter into a separate commercial license with Mistral before using the Model or its derivative works for any commercial purpose. The Licensee may contact Mistral, using this form: https://mistral.ai/contact/, to request a commercial license.

> "Model as a Service" means giving a third party access to the Model or its derivative works for inference or post-training by any means (for instance via API or hosted endpoints), in a manner that allows such third party to exercise meaningful control over the inputs, parameters, or training data. This does not include (a) end-user products with model capabilities solely embedded within specific features or harnesses, or (b) mere relaying of requests to models hosted by others.

"Meaningful control over the inputs" is so ambiguous as to be nearly meaningless. Does a model merely summarizing a user's submitted support tickets, give that user meaningful control over the inputs?

Don't get me wrong - I appreciate that Mistral needs to walk a fine line for its own sustainability, and that sustainability is a good thing! And I may just be an old person ranting at a cloud. But "open" used to mean something, back in my day!

> We want the PEP to be clear that it’s ultimately the JIT team’s responsibility to find solutions for these packages and tools, and how to deal with situations where a tool can’t be supported or made to work

Is it just me or is this absurdly impossible, to the point of willfully killing the project? Committing a team of brilliant compiler engineers to doing free consulting ad infinitum for every bit of tooling in the world, however hacked-together?

The alternative would be to have the bravery to say: this is the way forward to keep this language relevant into the future, and as a steering committee we collectively own that some tooling may be out of date. Instead, this is a signal that Python is going to rest on its laurels for a very long time.

https://pypi.org/project/uuid-utils/ is what you want :)

https://github.com/stevesimmons/uuid7/issues/1

I'd love to see this level of customization come to date and datetime-local popups, finding a meaningful path that preserves compatibility with the design languages of various platforms. If and when that happens, it will be because of the work of standardization working groups like Open UI and Interop.