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

[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.