Python language extension mechanism for Python 3000... Worth for PEP?

[John Roth]

Petr Prikryl wrote:
> Do you think that the following could became PEP (pre PEP).
> Please, read it, comment it, reformulate it,...
>
> Abstract
>
>   Introduction of the mechanism for language extensions via
>   modules written using other languages. Extensions of
>   Python could be done via special interpreter extensions.
>   From Python sources, the special modules would look like
>   other modules, with the Python API (the key feature from
>   the Python interpreter's point of view). Inside the
>   special modules, special language features could be
>   implemented and would possibly be interpreted by a
>   different interpreter (the key feature to please those who
>   want to use some special extensions).
>
>   The goal could be summarized as extension of the idea of
>   writing modules in Python or in C languages. Other kind of
>   modules could be introduced. Then Python would work not
>   only as a glue for modules and utilities, but could also
>   be the glue for different interpreters.
>
>
> Motivation
>
>   Note: The idea emerged when looking at the video
>   http://video.google.com/videoplay?docid=-6459339159268485356
>   and when thinking about it. The sequences from it will be
>   referenced like [video 2:10 - 2:30]. I do not want to be
>   the one of the group of the "everybody is the language
>   designer" [video 25:47]. The goal is rather to bypas the
>   problem mentioned in [video 25:35 - 27:50].
>
>   There are doubts whether some features should be added to
>   Python 3000 or whether some features are to be removed.
>   The goal is to get rid of the obsolete features but the
>   contradictory goal is not to break the backward
>   compatibility. [video 7:00 - 7:30 - 8:10 - 8:45]
>
>   There are some group of users of Python with special
>   interests or with some special tastes for programming
>   styles.
>
>   For example, some users like functional programming
>   (lambda, reduce, map,...). They have expressed so
>   eloquently their wishes that the Python 3000 is not to
>   remove lambda. On the other hand, only the (current)
>   simple form of lambda expressions will remain. [video
>   41:38 - 43:34] Possibly, the unpleased "functional" people
>   would be pleased if they could write some modules with
>   more powerful lambda that would be interpreted by some
>   special extension of the Python language interpreter.
>
>   The new, requested special features used only by minority
>   of programmers (but not by the unimportant minority) could
>   be implemented outside the core of the Python interpreter.
>
>
> Rationale
>
>   To keep the (Python) language clean, it is a good idea to
>   simplify the syntax as much as possible -- if it does not
>   lead to the loss of the power.
>
>   Some languages are better for some tasks. There will
>   always be people that want to extend the core of the
>   language to support their wishes. The extension of the
>   language via special kinds of modules would not upset the
>   pure Pythonistas and will please "the pure
>   functional-languages followers", for example.
>
>   There already is something similar available inside the
>   Python interpreter: some modules are implemented in the C
>   language. The key idea is that they offer the same kind of
>   interface that the modules written in Python do.
>
>   In some sense, Python interpreter is not interested in how
>   the results from the function call are obtained (whether
>   the content of the module must be processed by the Python
>   interpreter or whether the binary code will do it). In
>   some sense, the module written in C can be seen as using
>   "no-interpreter extension".
>
>   The idea of the module implementation language could be
>   extended (generalized) from "Python or C" to "Python or C
>   or Python-extension". The "Python extension" would be
>   implemented and maintained separately and would not spoil
>   the development of the core.
>
>   Technically, the goal is to separate the core of the
>   Python language from extensions that will be known in
>   future. In some sense, the mechanism is the adapter to the
>   something else to give it Python interface. The C/C++
>   would not be the only alternative to implement a module
>   used from a Python script.
>
>   If modules can be viewed as prefabricated building blocks
>   for writing the Python programs, the interpreter
>   extensions could be viewed as building blocks for
>   the interpreter functionality.
>
>   As modules, some interpreter extensions could be standard,
>   some could even be considered built-in, some could be
>   from third parties.
>
>   Some interpreter extensions could be used as a testbed for
>   adding new features:
>
>   For example, pure UTF-16 sources could be preprocessed by
>   some "experimental" interpreter extension to the form that
>   could be consumed by the core interpreter. And one day,
>   the UTF-8 or 8-bit with explicitly stated encoding can be
>   transformed to the only modern UTF-16 representation that
>   new sources should use. The designers of the core language
>   may freely decide to change the internals if they provide
>   the adapter via the extension.
>
>   Another "backward-compatibility extension" could check
>   whether some old feature could reliably be replaced by new
>   feature and translate the old source to the new one on the
>   fly.
>
>
>
> Backwards Compatibility
>
>   This would be new feature. It will not break the backward
>   compatibility.
>
>   From another point of view, the mechanism can even improve
>   the backward compatibility of Python 3000 for example by
>   embeding the Python 2.x interpreter inside and recognition
>   of the modules written for Python 2.x language version.
>   The oldness of the legacy module could be recognized by
>   the Python 3000 interpreter and the module could be passed
>   to the extension responsible for interpretation of the old
>   code.

PEP 3099 - Things that will not change in Python 3000 says:

Python will not have programmable syntax.

It seems Guido has made up  his mind.

John Roth