[issue4242] Classify language vs. impl-detail tests, step 1

Benjamin Peterson added the comment: Second patch applied in r70617. -- resolution: -> accepted status: open -> closed ___ Python tracker ___ ___

[issue4242] Classify language vs. impl-detail tests, step 1

Benjamin Peterson added the comment: Ok, I applied part of Armin's patch in r70615 modified to work with unittest's new test skipping ability. I think I will apply the test_descr part later. -- ___ Python tracker _

[issue4242] Classify language vs. impl-detail tests, step 1

Changes by Jim Baker : -- nosy: +jbaker ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/m

[issue4242] Classify language vs. impl-detail tests, step 1

Brett Cannon added the comment: On Tue, Jan 20, 2009 at 18:19, Terry J. Reedy wrote: > > Terry J. Reedy 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

[issue4242] Classify language vs. impl-detail tests, step 1

Terry J. Reedy 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. (

[issue4242] Classify language vs. impl-detail tests, step 1

Antoine Pitrou 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 gre

[issue4242] Classify language vs. impl-detail tests, step 1

Stefan Behnel 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 hav

[issue4242] Classify language vs. impl-detail tests, step 1

Changes by Leonardo Soto : -- nosy: +leosoto ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue4242] Classify language vs. impl-detail tests, step 1

Nick Coghlan 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 CPyt

[issue4242] Classify language vs. impl-detail tests, step 1

Antoine Pitrou 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 ___

[issue4242] Classify language vs. impl-detail tests, step 1

Nick Coghlan 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

[issue4242] Classify language vs. impl-detail tests, step 1

Stefan Behnel 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. Emulati

[issue4242] Classify language vs. impl-detail tests, step 1

Antoine Pitrou 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? -- nos

[issue4242] Classify language vs. impl-detail tests, step 1

Nick Coghlan 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 part

[issue4242] Classify language vs. impl-detail tests, step 1

Brett Cannon 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 tha

[issue4242] Classify language vs. impl-detail tests, step 1

Armin Rigo added the comment: Here is a summarizing implementation that accepts this interface: if check_impl_detail(): # only on CPython (default) if check_impl_detail(jython=True):# only on Jython if check_impl_detail(cpython=False): # everywhere except on CPyth

[issue4242] Classify language vs. impl-detail tests, step 1

Nick Coghlan <[EMAIL PROTECTED]> added the comment: My idea above won't really support Armin's idea of being able to exclude certain known-broken implementations. The check function would need to be handled differently to support that use case: # In test_support.py vm = platform.python_implement

[issue4242] Classify language vs. impl-detail tests, step 1

Armin Rigo <[EMAIL PROTECTED]> added the comment: Brett: in my experience the granularity is usually fine, and not coarse. A class decorator doesn't look too useful. A function decorator is useful, but not enough. We also need a flag that can be checked in the middle of a larger test. (See th

[issue4242] Classify language vs. impl-detail tests, step 1

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Interesting, I hadn't noticed that addition to the platform module for 2.6. A bit more verbose than sys.vm, but it would certainly do the trick :) In that case, I would suggest something along the lines of the following: vm = platform.python_

[issue4242] Classify language vs. impl-detail tests, step 1

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: On Thu, Oct 30, 2008 at 5:33 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Nick Coghlan <[EMAIL PROTECTED]> added the comment: > > I personally wonder if we should be moving towards a more systematic > means of identifying the underlying

[issue4242] Classify language vs. impl-detail tests, step 1

Nick Coghlan <[EMAIL PROTECTED]> added the comment: I personally wonder if we should be moving towards a more systematic means of identifying the underlying Python VM than the current fairly ad hoc use of sys.platform. By that I mean adding another sys attribute (e.g. sys.vm) which could be chec

[issue4242] Classify language vs. impl-detail tests, step 1

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: As I mentioned on Python-dev, I have implemented something similar to this in my testing branch. [1] http://code.python.org/users/benjamin.peterson/new_testing/main -- nosy: +benjamin.peterson

[issue4242] Classify language vs. impl-detail tests, step 1

Brett Cannon <[EMAIL PROTECTED]> added the comment: Based on your experience, Armin, is it worth having a class decorator as well/instead? The other comment I have is whether impl_detail is really the best name. Would something like cpython work out better to be more obvious that the test is spe

[issue4242] Classify language vs. impl-detail tests, step 1

Changes by Brett Cannon <[EMAIL PROTECTED]>: -- nosy: +brett.cannon ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list mail

[issue4242] Classify language vs. impl-detail tests, step 1

New submission from Armin Rigo <[EMAIL PROTECTED]>: This patch contains a first step towards classifying CPython tests into language tests and implementation-details tests. The patch is against the 2.7 trunk's test_descr.py. It is derived from a similar patch that we wrote for the 2.5's test_de