- 12 May, 2014 11 commits
-
-
Guido van Rossum authored
Merge 3.4->default: asyncio: Fix upstream issue 168: StreamReader.read(-1) from pipe may hang if data exceeds buffer limit.
-
Guido van Rossum authored
asyncio: Fix upstream issue 168: StreamReader.read(-1) from pipe may hang if data exceeds buffer limit.
-
Ned Deily authored
-
Ned Deily authored
source directory.
-
Terry Jan Reedy authored
-
Terry Jan Reedy authored
-
Terry Jan Reedy authored
-
Terry Jan Reedy authored
-
Terry Jan Reedy authored
-
Terry Jan Reedy authored
-
Terry Jan Reedy authored
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.
-
- 11 May, 2014 24 commits
-
-
Benjamin Peterson authored
-
Benjamin Peterson authored
-
Raymond Hettinger authored
-
Gregory P. Smith authored
s/Unix/POSIX/.
-
Gregory P. Smith authored
more accurate and sounds less like a strange tale of yore.
-
Gregory P. Smith authored
a Security Considerations section as preferred by both the devguide and documentation users who do not wish to go insane.
-
Benjamin Peterson authored
-
Benjamin Peterson authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Antoine Pitrou authored
-
Raymond Hettinger authored
-
Raymond Hettinger authored
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.
-
- 10 May, 2014 5 commits
-
-
Guido van Rossum authored
-
Guido van Rossum authored
-
Raymond Hettinger authored
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.
-
Jason R. Coombs authored
-
Jason R. Coombs authored
-