Larry Hastings added the comment:
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/test_zipfile.py. 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/bad_coding.py". 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")
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21520>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
