caught when executing test_strptime, test_logging, and test_time in that order
when the testing of "%c" occured. Suspect the cache was not being recreated
(the test passed when test_logging was forced to re-establish the locale).
Obtain the original locale in the documented way. This way actually
works for me.
Restore the original locale at the end, instead of forcing to "C".
Move the locale fiddling into the test driver instead of doing it as a
side effect of merely importing the module. I don't know why the test
is mucking with locale (and also added a comment saying so), but it
surely has no justification for doing that as an import side-effect.
Now whenever the locale-changing code executes, the locale-restoring code
will also get run.
arbitrary bytes before the actual zip compatible archive. Zipfiles
containing comments at the end of the file are still not supported.
Add a testcase to test_zipimport, and update NEWS.
This closes sf #775637 and sf #669036.
are satisfied in a case-insensitive manner, the attempt to import (the
non-existent) fcntl gets satisfied by FCNTL.py instead, and the tempfile
module defines a Unix-specific _set_cloexec() function in that case. As
a result, temp files can't be created then (blows up with an AttributeError
trying to reference fcntl.fcntl). This just popped up in the spambayes
project, where there is no apparent workaround (which is why I'm pushing
this in now).
If this doesn't happen, it leaves the locale in a state that can cause
other tests to fail. For example, running test_strptime,
test_logging, and test_time in that order.
skip over functions with private names (as indicated by the underscore
naming convention). The old default created too much of a risk that
user tests were being skipped inadvertently. Note, this change could
break code in the unlikely case that someone had intentionally put
failing tests in the docstrings of private functions. The breakage
is easily fixable by specifying the old behavior when calling testmod()
or Tester(). The more likely case is that the silent failure was
unintended and that the user needed to be informed so the test could be
fixed.
Extensions must still be configured manually and there is currently one
set of extension key bindings for all platforms.
Bring NEWS.txt up to date.
Update CREDITS.txt and idlever.py for release.
M NEWS.txt
M config-extensions.def
M extend.txt
M help.txt
M idlever.py
* It ran fine under "python regrtest.py test_warnings" but failed under
"python regrtest.py" presumably because other tests would add to
filtered warnings and not reset them at the end of the test.
* Converted to a unittest format for better control. Renamed
monkey() and unmonkey() to setUp() and tearDown().
* Increased coverage by testing all warnings in __builtin__.
* Increased coverage by testing regex matching of specific messages.
reported consistently with the *nix world. 'Lib/test/test_warnings.py'
came out as 'lib\test\test_warnings.py'. The basename is all we care
about so I used that.
Related to SF patch 723231 (which pointed out the problem, but didn't
fix it, just shut up the warning msg -- which was pointing out a dead-
serious bug!).
Bugfix candidate.
databases are associated with corruption problems, so I studied this code
carefully and ran some brutal stress tests. I didn't find any bugs,
although it's unclear whether this code *intends* that __setitem__ can
leave the directory file out of synch with the data file (so
if a dumbdbm isn't properly closed, and the value of an existing key
was ever replaced, corruption is almost certain, where "corruption"
means the directory file is out of synch with the data file).
Added many comments and generally modernized the code. Examples of the
latter: we have better ways of reading a whole file line-by-line now;
eval() now tolerates a trailing newline; the %r format code can be used
to avoid explicit repr/backtick calls; and the code often broke tuples
into their components when it was clearer and faster to just leave them
as tuples.
