The default seed is time.time().
Multiplied by 256 before truncating so that fractional seconds are used.
This way, two successive calls to random.seed() are much more likely
to produce different sequences.
The fix is confined to the Windows installer.
Not a bugfix candidate: the need for the new -n switch added here was
introduced by moving to the idlefork IDLE (so this change isn't needed
or helpful before 2.3).
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).
New Plan (releases to be made off the head, ongoing random 2.4 stuff
to be done on a short-lived branch, provided anyone is motivated enough
to create one).
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.
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.
behavior, creating many threads very quickly. A long debugging session
revealed that the Windows implementation of PyThread_start_new_thread()
was choked with "laziness" errors:
1. It checked MS _beginthread() for a failure return, but when that
happened it returned heap trash as the function result, instead of
an id of -1 (the proper error-return value).
2. It didn't consider that the Win32 CreateSemaphore() can fail.
3. When creating a great many threads very quickly, it's quite possible
that any particular bootstrap call can take virtually any amount of
time to return. But the code waited for a maximum of 5 seconds, and
didn't check to see whether the semaphore it was waiting for got
signaled. If it in fact timed out, the function could again return
heap trash as the function result. This is actually what confused
the test program, as the heap trash usually turned out to be 0, and
then multiple threads all got id 0 simultaneously, confusing the
hell out of threading.py's _active dict (mapping id to thread
object). A variety of baffling behaviors followed from that.
WRT #1 and #2, error returns are checked now, and "thread.error: can't
start new thread" gets raised now if a new thread (or new semaphore)
can't be created. WRT #3, we now wait for the semaphore without a
timeout.
Also removed useless local vrbls, folded long lines, and changed callobj
to a stack auto (it was going thru malloc/free instead, for no discernible
reason).
Bugfix candidate.
I won't have time to write real docs, but spent a lot of time adding
comments to his code and fleshing out the exported functions' docstrings.
There's probably opportunity to consolidate how docstrings get extracted
too, and the new code for that is probably better than the old code for
that (which strained mightily to recover from 2.2's new class/type
gimmicks).
SF bug #760703: SocketHandler and LogRecord don't work well together
SF bug #757821: logging module docs
Applied Vinay Sajip's patch with a few minor fixups and a NEWS item.
Patched __init__.py - added new function
makeLogRecord (for bug report 760703).
Patched handlers.py - updated some docstrings and
deleted some old commented-out code.
Patched test_logging.py to make use of makeLogRecord.
Patched liblogging.tex to fill documentation gaps (both
760703 and bug 757821).
now accepts "True" when a test expects "1", and similarly for "False"
versus "0". This is un-doctest-like, but on balance makes it much
more pleasant to write doctests that pass under 2.2 and 2.3. I expect
it to go away again, when 2.2 is forgotten. In the meantime, there's
a new doctest module constant that can be passed to a new optional
argument, if you want to turn this behavior off.
Note that this substitution is very simple-minded: the expected and
actual outputs have to consist of single tokens. No attempt is made,
e.g., to accept [True, False] when a test expects [1, 0]. This is a
simple hack for simple tests, and I intend to keep it that way.
fix the hangs on Win98SE when starting IDLE via "python" from a DOS box,
but did appear to make them harder to provoke. I closed that bug report
as being hopeless (and if someone wants to open it again, don't dare
assign it to me again <0.1 wink>).
evil - if the last grubbed buffer didn't happen to be the right one,
you couldn't remedy.
Mainline emacs compat - don't use third arg to buffer-substring (which
was for explicitly identifying the buffer in which to seek the
substring, and which turns out to be unnecessary).
have to insert it in front of other classes, nor do dirty tricks like
inserting a "dummy" HTTPHandler after a ProxyHandler when building an
opener with proxy support.
Python-Dev. Fixed typos in test comments. Added some trivial new test
guts to show the parallelism (now) among __delitem__, __setitem__ and
__getitem__ wrt error conditions.
Still a bugfix candidate for 2.2.3 final, but waiting for Fred to get a
chance to chime in.
Someone review this, please! Final releases are getting close, Fred
(the weakref guy) won't be around until Tuesday, and the pre-patch
code can indeed raise spurious RuntimeErrors in the presence of
threads or mutating comparison functions.
See the bug report for my confusions: I can't see any reason for why
__delitem__ iterated over the keys. The new one-liner implementation
is much faster, can't raise RuntimeError, and should be better-behaved
in all respects wrt threads.
New tests test_weak_keyed_bad_delitem and
test_weak_keyed_cascading_deletes fail before this patch.
Bugfix candidate for 2.2.3 too, if someone else agrees with this patch.
float_pow(): Don't let the platform pow() raise -1.0 to an integer power
anymore; at least glibc gets it wrong in some cases. Note that
math.pow() will continue to deliver wrong (but platform-native) results
in such cases.
tp_free is NULL or PyObject_Del at the end. Because it's a base type
it must call tp_free in its dealloc function, and because it's gc'able
it must not call PyObject_Del.
inherit_slots(): Don't inherit tp_free unless the type and its base
agree about whether they're gc'able. If the type is gc'able and the
base is not, and the base uses the default PyObject_Del for its
tp_free, give the type PyObject_GC_Del for its tp_free (the appropriate
default for a gc'able type).
cPickle.c: The Pickler and Unpickler types claim to be base classes
and gc'able, but their dealloc functions didn't call tp_free.
Repaired that. Also call PyType_Ready() on these typeobjects, so
that the correct (PyObject_GC_Del) default memory-freeing function
gets plugged into these types' tp_free slots.
one good use: a subclass adding a method to express the duration as
a number of hours (or minutes, or whatever else you want to add). The
native breakdown into days+seconds+us is often clumsy. Incidentally
moved a large chunk of object-initialization code closer to the top of
the file, to avoid worse forward-reference trickery.
- When redirecting, always use GET. This is common practice and
more-or-less sanctioned by the HTTP standard.
- Add a handler for 307 redirection, which becomes an error for POST,
but a regular redirect for GET and HEAD.
After removing that, two testers on machines where C: is not the system
drive reported that the installer suggested their system drive instead
of C:, and that's what they wanted it to do.
Reverted a Py2.3b1 change to iterator in subclasses of list and tuple.
They had been changed to use __getitem__ whenever it had been overriden
in the subclass.
This caused some usabilty and performance problems. Also, it was
inconsistent with the rest of python where many container methods
access the underlying object directly without first checking for
an overridden getter. Users needing a change in iterator behavior
should override it directly.