Antoine Pitrou [Thu, 14 Jan 2010 16:27:09 +0000 (16:27 +0000)]
Issue #7703: Add support for the new buffer API to functions of the
binascii module. Backported from py3k by Florent Xicluna, with some
additional tests.
Mark Dickinson [Thu, 14 Jan 2010 13:02:36 +0000 (13:02 +0000)]
Fix off-by-one error introduced in r77483. I have a test for this, but it currently fails due to a different dtoa.c bug; I'll add the test once that bug is fixed.
Skip Montanaro [Thu, 14 Jan 2010 01:12:34 +0000 (01:12 +0000)]
Update PyEval_EvalFrame to PyEval_EvalFrameEx. This looks to have been done
partially before. Also add a comment describing how this might have to work
with different versions of the interpreter.
Antoine Pitrou [Wed, 13 Jan 2010 07:55:48 +0000 (07:55 +0000)]
Issue #7622: Improve the split(), rsplit(), splitlines() and replace()
methods of bytes, bytearray and unicode objects by using a common
implementation based on stringlib's fast search. Patch by Florent Xicluna.
Mark Dickinson [Tue, 12 Jan 2010 22:23:56 +0000 (22:23 +0000)]
Issue #7632: Fix a problem with _Py_dg_strtod that could lead to
crashes in debug builds, for certain long numeric strings
corresponding to subnormal values.
Brett Cannon [Sun, 10 Jan 2010 02:56:19 +0000 (02:56 +0000)]
DeprecationWarning is now silent by default.
This was originally suggested by Guido, discussed on the stdlib-sig mailing
list, and given the OK by Guido directly to me. What this change essentially
means is that Python has taken a policy of silencing warnings that are only
of interest to developers by default. This should prevent users from seeing
warnings which are triggered by an application being run against a new
interpreter before the app developer has a chance to update their code.
Closes issue #7319. Thanks to Antoine Pitrou, Ezio Melotti, and Brian Curtin
for helping with the issue.
Antoine Pitrou [Fri, 8 Jan 2010 19:20:17 +0000 (19:20 +0000)]
Issue #7092: Remove py3k warning when importing cPickle. 2to3 handles
renaming of `cPickle` to `pickle`. The warning was annoying since there's
no alternative to cPickle if you care about performance. Patch by Florent
Xicluna.
Antoine Pitrou [Sun, 3 Jan 2010 22:29:56 +0000 (22:29 +0000)]
Issue #7471: Improve the performance of GzipFile's buffering mechanism,
and make it implement the `io.BufferedIOBase` ABC to allow for further
speedups by wrapping it in an `io.BufferedReader`. Patch by Nir Aides.
Kurt B. Kaiser [Sun, 3 Jan 2010 08:36:45 +0000 (08:36 +0000)]
r77152 to Doc/Makefile broke doc build due to (at least some) make
binaries running clean prereq after checkout.
1. So, fix the insane make call in build.sh - seems to solve it.
2. Fix a missing redirection.
3. Check in the rsync opts that actually work during upload.
Import all implementations of the hash algorithms (OpenSSL & builtin) and run
the test suite across all that are available. Warns about extension modules
that could not be imported when python was compiled with Py_DEBUG.
That warning could be made fatal but I didn't want to do that initially as
I suspect non setup.py based build processes (windows, any others?) won't
compile them all conditionally based on the Py_DEBUG setting today.
Issue #3745: Undo the requirement for new buffer API only objects to be passed
to hashlib functions in python 2.x. The module now uses the 's*' for argument
parsing which auto encodes unicode objects to the system default encoding for
us.
Always compile the all versions of the hashlib algorithm modules when Python
was compiled with Py_DEBUG defined. Otherwise the builtins are not compiled by
default for many developers due to OpenSSL being present, making it easier for
bugs to slip by. A future commit will add test code compare the behaviors of
all implementations when they are all available.
Antoine Pitrou [Sat, 2 Jan 2010 21:47:10 +0000 (21:47 +0000)]
Add tests for issue #7458: str.rfind() would crash when called with an invalid
start value. The offending code itself was removed as part of #7462.
This patch by Victor Stinner.
Mark Dickinson [Sat, 2 Jan 2010 14:45:40 +0000 (14:45 +0000)]
Refactor some longobject internals: PyLong_AsDouble and _PyLong_AsScaledDouble
(the latter renamed to _PyLong_Frexp) now use the same core code. The
exponent produced by _PyLong_Frexp now has type Py_ssize_t instead of the
previously used int, and no longer needs scaling by PyLong_SHIFT. This
frees the math module from having to know anything about the PyLong
implementation. This closes issue #5576.