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. -- http://mail.python.org/mailman/listinfo/python-list