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