Issue 21469: Mitigate risk of false positives with robotparser.
* Repair the broken link to norobots-rfc.txt.
* HTTP response codes >= 500 treated as a failed read rather than as a not
found. Not found means that we can assume the entire site is allowed. A 5xx
server error tells us nothing.
* A successful read() or parse() updates the mtime (which is defined to be "the
time the robots.txt file was last fetched").
* The can_fetch() method returns False unless we've had a read() with a 2xx or
4xx response. This avoids false positives in the case where a user calls
can_fetch() before calling read().
* I don't see any easy way to test this patch without hitting internet
resources that might change or without use of mock objects that wouldn't
provide must reassurance.
Antoine Pitrou [Mon, 12 May 2014 18:36:46 +0000 (20:36 +0200)]
Issue #16531: ipaddress.IPv4Network and ipaddress.IPv6Network now accept an (address, netmask) tuple argument, so as to easily construct network objects from existing addresses.
Terry Jan Reedy [Mon, 12 May 2014 03:32:32 +0000 (23:32 -0400)]
Issue #18104: Add idlelib/idle_test/htest.py with a few sample tests to begin
consolidating and improving human-validated tests of Idle. Change other files
as needed to work with htest. Running the module as __main__ runs all tests.
Gregory P. Smith [Sun, 11 May 2014 20:26:21 +0000 (13:26 -0700)]
Remove the warning-soup from the subprocess documentation by adding
a Security Considerations section as preferred by both the devguide
and documentation users who do not wish to go insane.
Issue #21424: Optimize heaqp.nlargest() to make fewer tuple comparisons.
Consolidates the logic for nlargest() into a single function so that
decoration tuples (elem,order) or (key, order, elem) only need to
be formed when a new element is added to the heap. Formerly, a tuple
was created for every element regardless of whether it was added to
the heap.
The change reduces the number of tuples created, the number of ordering
integers created, and total number of tuple comparisons.
Remove the redundant and poorly worded warning message.
The paragraph above already says, clearly and correctly, that
"However, being completely deterministic, it is not suitable for
all purposes, and is completely unsuitable for cryptographic purposes."
Also we should make any promises about SystemRandom or os.urandom()
being cryptographically secure (they may be, but be can't validate
that promise). Further, those are actual random number generators
not psuedo-random number generators.
Zachary Ware [Fri, 9 May 2014 14:07:50 +0000 (09:07 -0500)]
Issue #21141: The Windows build process no longer attempts to find Perl,
instead relying on OpenSSL source being configured and ready to build. The
``PCbuild\build_ssl.py`` script has been re-written and re-named to
``PCbuild\prepare_ssl.py``, and takes care of configuring OpenSSL source
for both 32 and 64 bit platforms. OpenSSL sources obtained from
svn.python.org will always be pre-configured and ready to build.
Tim Peters [Thu, 8 May 2014 22:43:25 +0000 (17:43 -0500)]
Merge from 3.4.
Issue #21435: Segfault in gc with cyclic trash
Changed the iteration logic in finalize_garbage() to tolerate objects vanishing
from the list as a side effect of executing a finalizer.
Tim Peters [Thu, 8 May 2014 22:42:19 +0000 (17:42 -0500)]
Issue #21435: Segfault in gc with cyclic trash
Changed the iteration logic in finalize_garbage() to tolerate objects vanishing
from the list as a side effect of executing a finalizer.
Merging from 3.3: The PyCOND_TIMEDWAIT must use microseconds for the timeout argument
in order to have the same resolution as pthreads condition variables.
At the same time, it must be large enough to accept 31 bits of
milliseconds, which is the maximum timeout value in the windows API.
A PY_LONG_LONG of microseconds fullfills both requirements.
This closes issue #20737
The PyCOND_TIMEDWAIT must use microseconds for the timeout argument
in order to have the same resolution as pthreads condition variables.
At the same time, it must be large enough to accept 31 bits of
milliseconds, which is the maximum timeout value in the windows API.
A PY_LONG_LONG of microseconds fullfills both requirements.
This closes issue #20737