classification
Title: Make CPython test package discoverable
Type: behavior Stage: patch review
Components: Tests Versions: Python 3.5, Python 3.4
process
Status: open Resolution:
Dependencies: 14408 16852 16888 16968 18258 20008 22002 Superseder:
Assigned To: ezio.melotti Nosy List: brett.cannon, chris.jerdonek, eric.araujo, eric.snow, ezio.melotti, python-dev, r.david.murray, serhiy.storchaka, terry.reedy, zach.ware
Priority: normal Keywords: patch

Created on 2012-12-22 01:02 by zach.ware, last changed 2014-07-21 14:26 by zach.ware.

Files
File name Uploaded Description Edit
issue16748.diff ezio.melotti, 2013-01-02 02:10 review
issue16748_genericpath.diff zach.ware, 2013-01-02 23:05 For test_*path.py review
issue16748_genericpath.v2.diff zach.ware, 2013-01-03 15:08 test_*path.py version 2 review
checkTestOverriding.diff serhiy.storchaka, 2013-01-11 10:49 Hacking patch which prints test methods overriding review
test_overriding.txt serhiy.storchaka, 2013-01-11 10:59 List of overridden test methods
Messages (49)
msg177913 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2012-12-22 01:02
As pointed out by Éric Araujo in msg177908 of issue16694, tests using the idiom presented in PEP 399 are subject to breakage of test discovery.  This issue's goal is to root out and fix all usages of this idiom.

So far, only test_heapq is known to be affected.

As for fixing the issue, each module get its own mixin class, or should a simple class such as:

class TestPyAndCMixin:
    module = None

be added to test.support?
msg177925 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-12-22 09:00
No need to add this trivial class to test.support. Mixin can have different parameters in additional to 'module' (see 16659).

I found a lot of usages of this idiom in tests and some of them can't be changed so simple (for example test_genericpath and test_functools).
msg177927 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2012-12-22 09:03
Éric, can you submit a test which exposes the problem?
msg178091 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-12-24 19:27
I won’t be online for the next two weeks.

I think there is a bug with Michael Foord, RDM and I where we talk about this very issue.
msg178140 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-12-25 15:36
Perhaps I misunderstood something, but test_decimal.py *is* using the
exact idiom from PEP-399 and it works. Why do you want to "fix" the
usage of this idiom?
msg178156 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2012-12-25 17:02
I finally understood the issue. So this does not work:

    ./python -m unittest discover Lib/test/ 'test_dec*.py'

Neither does this:

    ./python -m unittest discover Lib/test/ 'test_multipro*.py'

And this fails, too (still hanging):

    ./python -m unittest discover Lib/test/ 'test_thread*.py'

I'm not sure why tests in the Python test suite should be discoverable.
If I read this ...

    http://www.voidspace.org.uk/python/weblog/arch_d7_2009_05_30.shtml

..., the feature is for projects that don't have a test collection machinery.
msg178420 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2012-12-28 20:00
Making tests discoverable allows for the future possibility of dropping our custom test runner code and using more of unittest code by having regrtest use unittest's discovery code to find all tests.
msg178425 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2012-12-28 20:57
I should think that the first fix should be to the PEP. If I understand msg177908, that would mean removing unittest.TestCase as a base for ExampleTest and adding it as bases for AcceleratedExampleTest and PyExampleTest. Or have I missed something?
msg178428 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2012-12-28 21:12
That sounds right to me.

Note that PEP 399 is following older conventions that were laid down in a time when unittest did not *have* test discovery, so this is a new paradigm we'd like to move to (for the reasons Brett mentioned), and it may take a while to get there.  It applies to more than just the python/C accelerator distinction; it applies any time a base class plus specialized classes are used to construct test cases.  (I do this a bunch in the email tests, for example, and that has no accelerator.)
msg178737 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-01 17:39
I just came across the problem described here while reviewing #16694.

The idiom I used for the JSON tests[0] (and possibly a couple of other tests) when I rewrote them was to have something like:

class FooTest:
    # all the test methods here

class CFooTest(FooTest, unittest.TestCase):
    module = c_foo

class PyFooTest(FooTest, unittest.TestCase):
    module = py_foo

The reason to only have the subclasses inheriting from unittest.TestCase was exactly to avoid having FooTest as a discoverable TestCase.

I think PEP 399 should be updated and the tests should be fixed.
I don't think it's necessary to provide a base class as suggested in the first message (it's actually not even necessary to set the module to None, because eventually it will be set to either some cmodule or pymodule.  In case something goes wrong it's even better if the AttributeError says "self has no attribute 'module'" rather than "NoneType has no attribute 'somemeth'".)

@Brett, should I open a separate issue for the PEP 399 changes?

[0] see e.g.: Lib/test/json_tests/test_float.py and Lib/test/json_tests/__init__.py (note that here the idiom is a bit more complicated, because in addition to set the self.module, I also had to set additional attributes and work with different test files in the same package.  I also added additional tests in __init__ to make sure that import_fresh_module worked after adapting it to work with packages.)
msg178749 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2013-01-01 19:52
I created http://bugs.python.org/issue16835 to remind me to update PEP 399.
msg178795 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-02 02:10
Attached patch fixes Lib/test/test_heapq.py.
I also replaced the test_main() with unittest.main() and got rid of the code previously used to "test" reference leaks.  As it is the patch can be applied on 3.3/default.  If you think it should be backported to 2.7/3.2 too, the changes on test_main() should be reverted.
msg178812 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2013-01-02 14:16
Why remove the refleak tests? I'm sure Raymond put those in for a reason as I know he tries to reuse various objects a lot and this helped make sure he didn't mess anything up.

I don't think the tests need to be backported.
msg178831 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-02 18:18
> Why remove the refleak tests?

Because regrtest already provides the feature, so I don't see a reason to duplicate it here.  FWIW the same code is copy/pasted elsewhere too, e.g. in Lib/test/test_operator.py:438.
msg178835 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2013-01-02 18:30
The patch LGTM
msg178839 - (view) Author: Roundup Robot (python-dev) Date: 2013-01-02 19:23
New changeset 008bac4e181c by Ezio Melotti in branch '3.3':
#16748: test_heapq now works with unittest test discovery.
http://hg.python.org/cpython/rev/008bac4e181c

New changeset de6bac0a40cc by Ezio Melotti in branch 'default':
#16748: merge with 3.3.
http://hg.python.org/cpython/rev/de6bac0a40cc
msg178840 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-02 19:26
Fixed, thanks for the review!
msg178841 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-01-02 19:27
As I mentioned above, not only test_heapq uses this idiom, but a lot of other tests. Try to fix hard cases first: test_genericpath and test_functools.
msg178861 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2013-01-02 23:05
Here's a patch that should clear up test_genericpath.py (and other path tests).
msg178932 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-01-03 10:45
See also test_functools, test_xml_etree, test_bisect, test_bz2, test_warnings, test_decimal, test_datetime, json_tests, test_io, test_concurrent_futures, and many, many other undiscoverable tests.
msg178947 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2013-01-03 15:08
Here's version 2 of the genericpath patch.

Should I try to fix everything in one patch, or one patch per test module (or group of test modules like test_(generic|mac|nt|posix)path.py)?  And if separate, should each one get its own issue, or just keep them all here?
msg178956 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-01-03 15:46
I would suggest one patch and issue per test module.  If multiple test modules are related enough, they could go in one patch/issue; that's a judgement call.  We can make this issue dependent on those individual issues.
msg178958 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2013-01-03 15:58
Sounds good to me.  Shall I move the genericpath fix to a new issue, or leave that one here and begin starting new issues with the next one tackled?

Any volunteers for being nosied on new issues to make the dependency link back to this one for me? :)
msg178965 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2013-01-03 16:46
You can go ahead and start a new issue so it isn't forgotten about as this becomes a meta issue.

And you can always add me to the nosy, just can't guarantee how fast I will do the reviews. =)
msg179055 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-04 17:50
Feel free to add me to the nosy.
msg179286 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2013-01-07 22:07
I've come up with a semi-comprehensive list of the tests that cause ugly failures with test discovery.  Tests were run on 3.4 debug, on Windows 7 32bit without several of the 'external' projects built, using the command ``PCbuild\python_d.exe -m unittest discover Lib/test/ "test_x*.py"`` where 'x' was whatever it took to get a specific test or group of tests to run.

There are two basic causes of failure, and a couple of oddballs.

First up, tests that fail with discovery, but run fine with ``PCbuild\python_d.exe -m test test_name``:

test_array test_asyncore test_bisect test_bufio test_bytes test_codecs test_concurrent_futures test_configparser test_ctypes test_dbm test_decimal test_file test_format test_ftplib test_future3 test_hash test_imaplib test_import test_index test_io test_iterlen test_locale test_multiprocessing test_module test_osx_env test_pickle test_random test_robotparser test_runpy test_set test_shelve test_socket test_sqlite test_sys test_tarfile test_time test_univnewlines  test_warnings test_xml_etree

These 39 should be relatively straightforward fixes like heapq and genericpath have been.

The next group are tests that are properly skipped by the test package, but fail noisily with unittest discovery:

test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_crypt test_curses test_epoll test_fcntl test_gdb test_grp test_hashlib test_ioctl test_kqueue test_largefile test_nis test_openpty test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd test_readline test_resource test_smtpnet test_socketserver test_ssl test_syslog test_tcl test_threadsignals test_tk test_ttk_guionly test_ttk_textonly test_urllib2net test_wait3 test_wait4 test_winsound test_zipfile64

Some of these are skipped due to certain resources not being allowed, some don't have the proper module available.  In any case, discovery does not respond well to the skip methods used for each of them.

The 'oddballs' I mentioned before are as follows:

json_tests.test_fail leakers.test_gestalt test_glob test_json test_shutil test_urllib2_localnet

Each of these fail on my machine whichever way I run them.  I'm not sure if any of them actually have any issues with discovery, I'm merely listing them here for completeness' sake.  I will try to test them again myself on Linux later, and report back what I find.


If anyone else feels led to tackle any of these, please add me to the nosy list of any new issues filed.  I plan to eventually work through all of these myself, but don't want to duplicate effort :)

Thanks,

Zach Ware
msg179288 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-01-07 22:21
Great list, thanks.

The ones that fail to be run/skipped when run under discovery can probably be fixed by moving them to the more modern unittest 'skip' functions instead of depending on being run under regrtest and using the test.support resource functions.  When run directly they should not skip due to a resource not being set, but when run under regrtest (I'm not sure how you detect that but if there isn't currently a way we should make one via test.support) they should respect the resources.

Unittest doesn't yet have a concept of resources, but I believe there is an open issue for it, so at some point we will hopefully be able to move all resource management to unittest and out of regrtest.  But not yet.
msg179292 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-07 22:42
While we are at it, should we also move these tests to use unittest.main() instead of test_main() and similar?
msg179296 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-01-07 23:56
test_main makes it trivial to import a test file and run the test.
>>> import test/test_xxx as t; t.test_main()
I do not know the implications of unittest.main(), but I would dislike losing the above ability.
msg179297 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-01-08 00:09
As we discussed in another issue, you just need to change your pattern to:

>>> import unittest.main as runtest
>>> import test.test_xxx as t
>>> runtest(t)

Which granted is more typing if you are running just one test, but not much more if you are running more than one.  You could also put the import for unittest into your rc file.
msg179298 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-08 00:13
Without test_main you would have to do unittest.main(t, exit=False).  I'm not sure there's an easier way.
msg179305 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-08 02:11
> >>> import test.test_xxx as t; t.test_main()

As long as the module has "import unittest", you could also do the following, which has just 5 more characters :)

>>> import test.test_xxx as t; t.unittest.main(t)
msg179308 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-08 02:31
One more.  Since unittest imports strings, you can also do:

>>> import unittest as u; u.main("test.test_xxx")
msg179316 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-08 06:41
I think that's the last nail in the coffin of test_main.
Terry, do you agree?
msg179319 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-01-08 08:01
There are tests outside of Lib/test/ hierarchy.
msg179347 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-01-08 13:03
Yes, but not many, and not as many as there used to be.  I'd like to see them all moved, but met resistance on that front.  It may be that those just can't be run using unittest discovery, and perhaps that will eventually convince the maintainers to move them.  But probably not until a number of years from now :)
msg179349 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2013-01-08 13:04
Also, it may be possible to add unittest discovery hooks to the stubs that *are* in Lib/test.
msg179361 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2013-01-08 16:32
It's totally doable to set up stubs in Lib/test to use test discovery on those tests which exist outside of that directory. test_importlib actually has some code for that left over from when it lived in Lib/importlib/test: http://hg.python.org/cpython/file/4617b7ac302a/Lib/test/test_importlib/__init__.py
msg179370 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-08 20:47
> Also, it may be possible to add unittest discovery hooks to the stubs that *are* in Lib/test.

The load_tests protocol (2.7, 3.2+) seems like the right approach for this:

http://docs.python.org/dev/library/unittest.html#load-tests-protocol
msg179634 - (view) Author: Ezio Melotti (ezio.melotti) * (Python committer) Date: 2013-01-11 06:06
> There are tests outside of Lib/test/ hierarchy.

See #10572.
msg179635 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-11 06:18
There are lots of modules to change here.  I wonder if some or most of this couldn't be automated.

For example, is there any reason we couldn't write a script to check for the type of test duplication fixed documentation-wise in issue 16835?  We could use such a script to find the classes that need to be updated when removing test_main (or to double-check existing test modules).

I don't know if there are ever times we want such duplication.
msg179663 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-11 10:26
As suggested in the previous comment, here is simple code to find candidates for test duplication (TestCase subclasses subclassing other TestCase classes):

def find_dupes(mod):
    objects = [getattr(mod, name) for name in sorted(dir(mod))]
    classes = [obj for obj in objects if isinstance(obj, type) and
               issubclass(obj, unittest.TestCase)]
    for c in classes:
        for d in classes:
            if c is not d and issubclass(d, c):
                print("%s: %s < %s" % (mod.__name__, c.__name__, d.__name__))

Out of curiosity, I ran a modified form of this against all test modules to find which ones fit this pattern and *already* rely on unittest discovery (i.e. don't have test_main()).  We might want to adjust these as well.  There were four: test_asyncore, test_configparser, test_heapq, test_ipaddress
msg179665 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2013-01-11 10:49
Here is a dirty patch which hacks unittest to search possible test overriding. Just apply the patch and run regression tests.
msg179956 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2013-01-14 17:19
Chris:
> There are lots of modules to change here.  I wonder if some or most of 
> this couldn't be automated.

Possibly, but I don't mind going through individually if Ezio (or others) don't mind committing individually.  From what I've seen, the test suite is varied enough within itself that it would be pretty hard to properly automate the changes I've been making.  Also, I'm of the opinion that we'll end up with a higher quality result doing things by hand anyway.
msg179971 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-14 19:45
> Also, I'm of the opinion that we'll end up with a higher quality result doing things by hand anyway.

Automation doesn't (and shouldn't) preclude careful review and modifications by hand.  My point was that it seems like it might be able to get you, say, 80% of the way there (e.g. by deleting test_main(), determining which classes are called by test_main(), adding ", unittest.TestCase", creating stub classes that could be retained or deleted).  Or at least provide some additional checks or info.  There are nearly 400 test files using test_main(), no?
msg179980 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2013-01-14 21:53
For the conversion from test_main() to unittest.main(), I could certainly see automation helping a lot; most cases are very simple.  But really, that issue is somewhat tangential to this one and in my last message I was thinking from the perspective of just the 80 or so modules that completely fail test discovery otherwise.  I believe that trying to automate those would be more trouble than it's worth.  Especially if issue 16935 is fixed, as that will knock out most of the tests I listed above that failed to skip properly.
msg179996 - (view) Author: Chris Jerdonek (chris.jerdonek) * (Python committer) Date: 2013-01-15 01:45
Okay, well the title of this issue is "Make CPython test package discoverable," so as part of that we should be confirming that test discovery finds the same tests that test_main() runs (and if not, to understand why and/or make them the same).
msg189292 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-05-15 18:43
Chris: >>> import unittest as u; u.main("test.test_xxx")
Ezio: I think that's the last nail in the coffin of test_main.
Terry, do you agree?

Belated answer: now that I use and understand the idiom, yes.

Chris: The load_tests protocol (2.7, 3.2+) seems like the right approach for [tests in directories outside of /test].

I am using that in the new idlelib/idle_test/__init__.py. But perhaps the load_tests() example in the doc, which I copied, should be changed from 'do nothing' to 'discover all tests in the directory' as a more useful default.
msg191487 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2013-06-19 16:54
So many things have been fixed since I last made a list of failing modules that it seemed like time to make a new one.  First, failing modules that already have open issues with patches:

- test_codecmaps* (issue18258)
- test_concurrent_futures (issue16968)
- test_locale (issue17767)
- test_multiprocessing (issue17778)
- test_socket (issue14408 -- incomplete patch, waiting on resolution of issue16968 for how to handle thread/process reaping)



Other tests that fail, that may be the fault of my test machine rather than the tests themselves (or, ones that I'd like others to try before I call them broken):

- test_urllib2net (fails on my machine on normal runs due to network setup)
- test_shutil (fails on my machine on normal runs for unknown reasons relating to symlinks)



The below tests fail for reasons that I expect to probably be related to test run order, as all of them pass when narrowing the pattern to match only them (e.g., "test_dbm*.py" rather than "test_*.py"):

- test_dbm (had a permission error on a test file)
- test_venv (tried to delete a temp dir that was unexpectedly non-empty)
- test_wsgiref (failure in testEnviron)
- test_logging (failure in test_warnings)
- test_inspect (had some issue with locating its test files)



This leaves only 6 other tests that fail due to improper inheritance, setup done in test_main rather than setUp/setUpClass/setUpModule, or other reasons directly related to discovery:

- test_decimal
- test_largefile
- test_pickle (pickletester)
- test_runpy
- test_shelve
- test_xml_etree



Other tests that need some manner of attention related to discovery:

- test_json: it half-uses discovery, it could use it completely
- test_importlib: about the same as test_json
- leakers package: either rename to non-discoverable names or otherwise make leakers.test_gestalt (in particular) not report an error when discovered.



This may not be a comprehensive list, but it does cover all of the most obvious failures that remain.
History
Date User Action Args
2015-10-02 21:21:30haypounlinkissue10967 dependencies
2014-07-21 14:26:35zach.waresetdependencies: + Make full use of test discovery in test subpackages
versions: + Python 3.5, - Python 3.3
2013-12-17 21:26:38zach.waresetdependencies: + Support ./python -m unittest in test_socket, Fix test discovery for test_concurrent_futures.py, Fix test discovery for test_codecmaps*.py, Clean up/refactor/make discoverable test_decimal
2013-06-19 16:54:28zach.waresetmessages: + msg191487
2013-05-15 18:43:16terry.reedysetmessages: + msg189292
2013-02-28 19:40:57chris.jerdoneklinkissue10967 dependencies
2013-01-26 08:37:07eric.snowsetnosy: + eric.snow
2013-01-15 01:45:26chris.jerdoneksetmessages: + msg179996
2013-01-14 21:53:44zach.waresetmessages: + msg179980
2013-01-14 19:45:42chris.jerdoneksetmessages: + msg179971
2013-01-14 17:19:56zach.waresetmessages: + msg179956
2013-01-11 10:59:24serhiy.storchakasetfiles: + test_overriding.txt
2013-01-11 10:49:04serhiy.storchakasetfiles: + checkTestOverriding.diff

messages: + msg179665
2013-01-11 10:26:34chris.jerdoneksetmessages: + msg179663
2013-01-11 06:18:56chris.jerdoneksetmessages: + msg179635
2013-01-11 06:06:33ezio.melottisetmessages: + msg179634
2013-01-08 20:47:46chris.jerdoneksetmessages: + msg179370
2013-01-08 16:32:43brett.cannonsetmessages: + msg179361
2013-01-08 13:04:45r.david.murraysetmessages: + msg179349
2013-01-08 13:03:41r.david.murraysetmessages: + msg179347
2013-01-08 08:01:18serhiy.storchakasetmessages: + msg179319
2013-01-08 06:41:26ezio.melottisetmessages: + msg179316
2013-01-08 02:31:46chris.jerdoneksetmessages: + msg179308
2013-01-08 02:11:59chris.jerdoneksetnosy: + chris.jerdonek
messages: + msg179305
2013-01-08 00:13:54ezio.melottisetmessages: + msg179298
2013-01-08 00:09:25r.david.murraysetmessages: + msg179297
2013-01-07 23:56:01terry.reedysetmessages: + msg179296
2013-01-07 22:42:58ezio.melottisetdependencies: + Fix test discovery for test_array.py
messages: + msg179292
2013-01-07 22:21:48r.david.murraysetmessages: + msg179288
2013-01-07 22:07:44zach.waresetmessages: + msg179286
2013-01-04 17:50:08ezio.melottisetmessages: + msg179055
2013-01-03 17:14:30skrahsetnosy: - skrah
2013-01-03 17:12:44brett.cannonsetdependencies: + Fix test discovery for test_genericpath.py
2013-01-03 16:46:36brett.cannonsetmessages: + msg178965
2013-01-03 15:58:53zach.waresetmessages: + msg178958
2013-01-03 15:46:19r.david.murraysetmessages: + msg178956
2013-01-03 15:08:29zach.waresetfiles: + issue16748_genericpath.v2.diff

messages: + msg178947
2013-01-03 10:45:37serhiy.storchakasetmessages: + msg178932
stage: resolved -> patch review
2013-01-02 23:05:46zach.waresetfiles: + issue16748_genericpath.diff
resolution: fixed ->
messages: + msg178861

title: Ensure test discovery doesn't break for modules testing C and Python implementations -> Make CPython test package discoverable
2013-01-02 19:27:40serhiy.storchakasetstatus: closed -> open

messages: + msg178841
2013-01-02 19:26:01ezio.melottisetstatus: open -> closed
versions: - Python 2.7, Python 3.2
messages: + msg178840

resolution: fixed
stage: patch review -> resolved
2013-01-02 19:23:11python-devsetnosy: + python-dev
messages: + msg178839
2013-01-02 18:30:00brett.cannonsetmessages: + msg178835
2013-01-02 18:18:59ezio.melottisetmessages: + msg178831
2013-01-02 14:16:42brett.cannonsetmessages: + msg178812
2013-01-02 02:10:53ezio.melottisetfiles: + issue16748.diff
keywords: + patch
messages: + msg178795

stage: test needed -> patch review
2013-01-01 19:52:07brett.cannonsetmessages: + msg178749
2013-01-01 17:39:58ezio.melottisetassignee: ezio.melotti
messages: + msg178737
2012-12-28 21:12:49r.david.murraysetnosy: + r.david.murray
messages: + msg178428
2012-12-28 20:57:24terry.reedysetnosy: + terry.reedy
messages: + msg178425
2012-12-28 20:00:08brett.cannonsetmessages: + msg178420
2012-12-25 17:02:18skrahsetmessages: + msg178156
2012-12-25 15:36:37skrahsetnosy: + skrah
messages: + msg178140
2012-12-25 12:30:24ezio.melottisetnosy: + ezio.melotti
2012-12-24 19:27:18eric.araujosetmessages: + msg178091
2012-12-22 09:03:51serhiy.storchakasetmessages: + msg177927
stage: test needed
2012-12-22 09:00:04serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg177925
2012-12-22 03:17:30brett.cannonsetnosy: + brett.cannon
2012-12-22 01:02:27zach.warecreate