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 larry
Recipients georg.brandl, larry
Date 2014-05-18.16:03:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Here's an eye-wateringly-thorough description of the bug for the sake of posterity.

The test code in question is test_write_filtered_python_package() in Lib/test/   This function uses PyZipFile to build a zipfile from the contents of the "Lib/test" directory.  PyZipFile scans for .py files, then compiles them into .pyc or .pyo files and adds the compiled result.

The test code actually reuses the PyZipFile object three times:

The first try succeeds, but raises some warnings because of some deliberately troublesome files in that directory that upset the compiler.  These files all contain the substring "bad" in their name, like "Lib/test/".  The warnings are written to stdout; the test captures stdout and scans for the errors.  When this function is done, the zipfile contains .pyc files of all the files in Lib/test except for the ones with the substring "bad" in their name.

The second try succeeds, but ignores every file because of a "filterfunc" passed in that always returns False.  It's effectively a no-op--no files are added to the zipfile.  The test then scans the output to make sure no warnings were issued.

The third try succeeds.  It uses the "filterfunc" parameter to selectively skip the "bad" files, then scans stdout to ensure that no warnings were issued there.  However, since it's re-adding all the other files to the zipfile, this does issue a zillion UserWarning assert warnings.  The code suppresses these with a "self.assertWarns(UserWarning)" context manager.

So here's the bug.  If you untarred Python into "/tmp/goodidea", then the test works as expected.  But if you untar Python into "/tmp/badidea", then the filterfunc in the third test ignores *every* file, because *every* file contains the substring "bad".  Therefore it never adds a single file.  And therefore it never fires the UserWarning about redundantly adding a file.  Since UserWarning is never issued, and the test is supposed to issue it, the assertWarns context manager flags the test as a failure.

The easy fix: change the filterfunc to be far more selective, only filtering out paths containing the substring "Lib/test/bad".  This would still fail if you untarred Python to "/tmp/Lib/test/bad/", but hopefully nobody will do *that*.

Perhaps a still-better approach would be 
  lambda path: os.path.basename(path).startswith("bad")
Date User Action Args
2014-05-18 16:03:32larrysetrecipients: + larry, georg.brandl
2014-05-18 16:03:32larrysetmessageid: <>
2014-05-18 16:03:32larrylinkissue21520 messages
2014-05-18 16:03:31larrycreate