Mailing List Archive

Brett Cannon <brett@python.org> added the comment:

At the language summit I actually plan on proposing separating out the
Python the language and standard library from CPython. That would make
this patch mostly unneeded as the CPython-specific tests and code would
simply be kept separate from the language code that PyPy and other VMs
would use.

Because of this I am not going to do any code review right now in hopes
that my more radical proposal goes through.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Nick Coghlan <ncoghlan@gmail.com> added the comment:

Physically splitting the code base? Ick... I'd prefer just to flag the
parts of the test suite that are optional and let the developers of
other implementations pick and choose as to how much of the pure Python
code they want to adopt to pass the non-optional parts of the test-suite...

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Antoine Pitrou <pitrou@free.fr> added the comment:

The patch looks nice to me. (I'm curious why you call gc.collect()
several times in a row, though)

However, since it is an important change in the long run, perhaps the
specifics could be further discussed on python-dev before taking a decision?

----------
nosy: +pitrou

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Stefan Behnel <scoder@users.sourceforge.net> added the comment:

I would definitely appreciate having a well-defined set of "required
tests" that Cython should pass for compliance.

However, something like sys.vm won't easily work for Cython: it runs
within the CPython VM but only after converting the Python code to C.
Emulating platform.python_implementation() to make it return "Cython"
does not sound correct.

You can currently detect Cython compilation by doing this:

import cython
print cython.compiled

Obviously, the import will fail when running as Python code without
having Cython installed.

However, in Cython, you would often get a compile time error in cases
where implementation details apply, so checking for implementation
details programmatically may not work at all.

----------
nosy: +scoder

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Nick Coghlan <ncoghlan@gmail.com> added the comment:

Would a C API in CPython to set the value returned by sys.vm be enough
to help Cython out Stefan?

Such a feature would help with any CPython based variant - the
implementers could either leave sys.vm as "cpython" and attempt to be
fully compatible, or else set it to something different (e.g "stackless"
or "cython") and target the common subset of the test suite.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Antoine Pitrou <pitrou@free.fr> added the comment:

Why would Cython be affected? This is about tests of the stdlib, which
have nothing to whether you use Cython or not.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Nick Coghlan <ncoghlan@gmail.com> added the comment:

I got the impression from Stefan's question that he would like to be
able to run the stdlib tests with Cython enabled for all of the stdlib
Python modules and know which tests still needed to pass and which could
be safely skipped as being specific to vanilla CPython.

Without some way to change the value of sys.vm (either from Python or
from C), that kind of thing wouldn't be possible.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Changes by Leonardo Soto <leo.soto@gmail.com>:


----------
nosy: +leosoto

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Stefan Behnel <scoder@users.sourceforge.net> added the comment:

@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 :)

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Antoine Pitrou <pitrou@free.fr> added the comment:

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

Wow! I guess I was still living in the Pyrex era... That's an impressive
achievement.
So, let me retract what I said about Cython not being relevant to this
issue.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Terry J. Reedy <tjreedy@udel.edu> added the comment:

Like Brett, I think the long term solution is to segregate
implementation-specific tests into a separate file or subdirectory of
files. Then the main directory of tests could (and I would like)
constitute an executable definition-by-example for the language. (To
aid this, I would also like the naming of files and tests and sequencing
of tests within files to reflect the structure of the manual as much as
possible -- and would help to make it so. Separate patches of course.)

Would alternative implementors prefer to wait or have a *temporary*
addition to test_support?

If something is added, I would give it a leading underscore name and
document it as something probably temporary for alternate
implementations to use until a permanent solution is implemented.

----------
nosy: +tjreedy

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Brett Cannon <brett@python.org> added the comment:

On Tue, Jan 20, 2009 at 18:19, Terry J. Reedy <report@bugs.python.org> wrote:
>
> Terry J. Reedy <tjreedy@udel.edu> added the comment:
>
> Like Brett, I think the long term solution is to segregate
> implementation-specific tests into a separate file or subdirectory of
> files. Then the main directory of tests could (and I would like)
> constitute an executable definition-by-example for the language. (To
> aid this, I would also like the naming of files and tests and sequencing
> of tests within files to reflect the structure of the manual as much as
> possible -- and would help to make it so. Separate patches of course.)
>
> Would alternative implementors prefer to wait or have a *temporary*
> addition to test_support?

Well, if the idea of breaking out the language stuff into its own
repository happens, then the tests will have to be crawled through
anyway so decorating now to act as a marker of what has to be
separated out shouldn't lead to too much extra work.

>
> If something is added, I would give it a leading underscore name and
> document it as something probably temporary for alternate
> implementations to use until a permanent solution is implemented.

Well, this might be the permanent solution. Plus the entire test
directory tends to be somewhat optional thanks to the Linux distros
leaving it out most of the time so even if it is put in there they can
just not document it.

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Changes by Jim Baker <jbaker@zyasoft.com>:


----------
nosy: +jbaker

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue4242>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com