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

Discussion in 'Python' started by Petr Prikryl, Nov 30, 2006.

  1. Petr Prikryl

    Petr Prikryl Guest

    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.
    Petr Prikryl, Nov 30, 2006
    #1
    1. Advertising

  2. Petr Prikryl

    John Roth Guest

    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
    John Roth, Nov 30, 2006
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Petr Prikryl
    Replies:
    3
    Views:
    271
    Dieter Maurer
    Sep 21, 2005
  2. Replies:
    2
    Views:
    497
    Alex Martelli
    Jul 3, 2007
  3. Jean-Paul Calderone
    Replies:
    4
    Views:
    520
  4. Curt Hibbs
    Replies:
    1
    Views:
    230
    olof sivertsson
    Dec 18, 2005
  5. Curt Hibbs
    Replies:
    2
    Views:
    233
    Curt Hibbs
    Dec 18, 2005
Loading...

Share This Page