This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author scoder
Recipients Carl.Friedrich.Bolz, arigo, benjamin.peterson, brett.cannon, leosoto, ncoghlan, pitrou, scoder
Date 2009-01-20.22:06:40
SpamBayes Score 7.2164497e-16
Marked as misclassified No
Message-id <1232489203.21.0.254906955747.issue4242@psf.upfronthosting.co.za>
In-reply-to
Content
@Antoine: Cython already compiles a major part of CPython's test suite
successfully (although we didn't actually try to compile the stdlib
itself but only the tests). It's an announced goal for Cython 1.0 to
compile 'all' Python code, and it would be great to have an official
subset of the test suite that would allow us to prove compliance and to
know when we're done.

Thinking about this some more, I guess that fairness would require us to
also compile the pure Python modules in the stdlib that are being
tested. I really like that idea. That would allow a Cython-enabled
CPython to compile its entire stdlib into fast extension modules and to
ship them right next to the pure Python code modules, so that people
could still read the Python code that gets executed at C speed. Looks
like all we'd need to do is to install a global import hook for .py
files (but that's definitely off-topic for this bug).

@Nick: It's not a technical problem. We could special case sys.vm in
Cython by simply replacing it by a constant string when we find it in
the source tree (that should do for 'normal' usage, although
"getattr(sys, vm_string)" won't work). Being able to change the value of
sys.vm programmatically isn't a good solution, as it would affect all
Python code in the VM, not only code that was compiled by Cython.

I'm more concerned about the semantics. It wouldn't be correct to tell
code that it runs in Cython when it was actually interested in the *VM*
it runs in. But some things might still behave different in Cython than
in CPython, due to static compilation, exception handling nuances, the
placement of reference counting calls, etc. The information about the
running VM isn't enough here, whereas "platform.python_implementation()"
makes at least a bit more sense by its name. The main problem seems to
be that Cython has some specialties in its own right, while it inherits
others from CPython. So code that branches based on
"platform.python_implementation()" must be aware of both. There will
definitely be cases where CPython will work but Cython compilation won't
(and maybe even vice versa :)
History
Date User Action Args
2009-01-20 22:06:43scodersetrecipients: + scoder, brett.cannon, arigo, ncoghlan, pitrou, Carl.Friedrich.Bolz, benjamin.peterson, leosoto
2009-01-20 22:06:43scodersetmessageid: <1232489203.21.0.254906955747.issue4242@psf.upfronthosting.co.za>
2009-01-20 22:06:42scoderlinkissue4242 messages
2009-01-20 22:06:41scodercreate