Python language extension mechanism for Python 3000... Worth for PEP?
JohnRoth1 at jhrothjr.com
Thu Nov 30 15:39:30 CET 2006
Petr Prikryl wrote:
> Do you think that the following could became PEP (pre PEP).
> Please, read it, comment it, reformulate it,...
> 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.
> Note: The idea emerged when looking at the video
> 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
> 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.
> 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
> Backwards Compatibility
> This would be new feature. It will not break the backward
> 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
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.
More information about the Python-list