Guido van Rossum
guido at python.org
Tue Mar 29 22:29:33 CEST 2011
On Tue, Mar 29, 2011 at 11:58 AM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> Forgive me if I am wildly off, but in that
> case it would require a builder to be in a C module, or for it to tie into
> the existing mechanism CPython uses to build .pyc files and to use them.
It's worse than that. The compiler that generates the .pyc file cannot
have knowledge of the environment in which the code will be executed
-- and that includes things like importing modules.
On Tue, Mar 29, 2011 at 12:23 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> Another thing I had not considered is the effect this would have on the
> other implementations. I have no clue as to how difficult all this would be
> to accomplish in the DLR, or the JVM, or pypy, or others. I have no doubt
> that they could find a way, but for all I know it would put an undue burden
> on them. Is that a criteria for Python feature consideration, the impact on
> other implementations of adding the feature?
For a feature that changes the language syntax, most certainly.
For a feature that adds something to the stdlib, yes, unless you are
offering functionality that would simply make no sense in another
implementation. (E.g. 'dis', which you mentioned before, gets a pass
because it refers to the bytecode which is a CPython-exclusive
feature. But it is pretty much only used for interactive debugging.)
Note that things weren't always like this. But now they are. We are
striving to increase compatibility between the different Python
implementations so as to reduce the pain of users switching
implementations. (E.g. it would be a shame if your code would run
twice as fast on PyPy but you can't port it because you happen to use
one little CPython-only feature.)
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas