metaprogramming and politics

I’d see to base syntax and semantics on Python3, but strip and rebase it:

• no C: implement the interpreter in RPython, get a JIT for free and implementation bits from PyPy’s Python interpreter (parsing, IO, etc.)
• no drags-you-down batteries: lean interpreter core and a standard battery distro which is tested against the last N interpreter versions + current
• no yield: use greenlets to implement all of what yield provides and more
• no underlying blocking on IO: base it all on event loop, yet provide synchronous programming model through greenlets
• no c-level API nor ctypes: use cffi to interface with c-libraries
• no global state: just support state bound to execution context/stack
• no GIL: support free threading and Automatic Mutual Exclusion for dealing with shared state
• no setup.py: have a thought-through story and tools from the start for packaging, installation, depending/interfacing between packages
• no import, no sys.modules: provide an object with which you can access other packages’s objects and introspect/interact with one’s own package
• no testing as an afterthought: everything needs to be easily testable, empowered assert statement and branch-coverage supported from the core.
• no extensibility as an afterthought: support plugins and loose coupling through builtin 1:N calling mechanism (event notification on steroids)
• no unsafe code: support IO/CPU/RAM sandboxing as a core feature
• no NIH syndrome: provide a bridge to a virtualenv’ed Python interpreter allowing to leverage existing good crap

Anything else? Probably! Discussion needed? Certainly. Unrealistic? Depends on who would participate — almost all of the above has projects, PEPs and code showcasing viability.

Btw, did you know that when we started PyPy we initially did this under the heading of “Minimal Python”? Some of the above ideas above and their underlying motivations were already mentioned when I invited to the first PyPy sprint almost 10 years ago:

http://mail.python.org/pipermail/python-dev/2003-January/032427.html

I learned since then that Python has more complex innards than it seems but i still believe it could be both simpler and more powerful.

holger