> Later, I closed my pysandbox beause it was "broken by design":
https://lwn.net/Articles/574215/

Thanks for the link, insightful. Still unclear, by design of what it's broken ;-).


> Paul Sokolovsky wrote in bpo-36220 than his idea is also to implement a sandbox

Depends on the definition of "sandbox". If it's "But I was contacted by
different companies interested to use pysandbox in production on their
web application.  So I think that there is a real need to execute
arbitrary untrusted code." (re: https://lwn.net/Articles/574323/). Then no, I definitely not developing such a "sandbox".

If by "sandbox" you mean "ability to override some namespacing rules used by Python", then yep, I, and other folks (according to these >1 issue reports) interested in that. It's unclear why demise of your particular project should affect all other possible projects interested in dealing with namespacing matters. I for example interested in study of some properties of corpus of Python code. I can understand your claim that you "own" the partial features you introduced, but claiming them to be useful for only our own usecase is somewhat ..., well, short-sighted, just as claiming that all such uses should cease and desist is as insightful as claiming that, for example, list comprehensions are useless because you faced a case when one needs to be rewritten as explicit loop.

> IMHO we should reject dict subclasses to make Python (especially ceval.c) more efficient.

I'm afraid efficiency story for CPython is irrecoverably lost, unless someone secretly works on adding JIT to it, but as we know, JIT work happily happens outside of it, in multiples. CPython still can either serve as a common platform for prototyping and experimentation, or complicate that by a committee fiat. Because the current situation is that CPython is too dynamic to be "slow", but not enough dynamic to perform useful instrumentation easily. For example, to comfortably do study on the proportions of actual usage of various "overdynamic" features.