P
Petr Prikryl
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.
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.