svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r83833 | florent.xicluna | 2010-08-08 18:25:27 +0200 (dim., 08 août 2010) | 2 lines
Add test case for the HTTPResponse being an iterable. Follow-up of issue #4608.
........
r83838 | florent.xicluna | 2010-08-08 20:03:44 +0200 (dim., 08 août 2010) | 2 lines
Typo.
........
r83839 | florent.xicluna | 2010-08-08 20:06:13 +0200 (dim., 08 août 2010) | 2 lines
Issue #7564: Skip test_ioctl if another process is attached to /dev/tty.
........
r83859 | florent.xicluna | 2010-08-09 00:07:16 +0200 (lun., 09 août 2010) | 2 lines
Fix#8530: Prevent stringlib fastsearch from reading beyond the front of an array.
........
r83878 | florent.xicluna | 2010-08-09 10:29:08 +0200 (lun., 09 août 2010) | 1 line
Merge the 2to3 script from /sandbox/trunk/2to3/2to3, revision 72867 (latest).
........
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r83400 | mark.dickinson | 2010-08-01 11:41:49 +0100 (Sun, 01 Aug 2010) | 7 lines
Issue #9416: Fix some issues with complex formatting where the
output with no type specifier failed to match the str output:
- format(complex(-0.0, 2.0), '-') omitted the real part from the output,
- format(complex(0.0, 2.0), '-') included a sign and parentheses.
........
int, long, and float __format__(), and it keeps their implementation
in sync with py3k.
Also added PyOS_double_to_string. This is the "fallback" version
that's also available in trunk, and should be kept in sync with that
code. I'll add an issue to document PyOS_double_to_string in the C
API.
There are many internal cleanups. Externally visible changes include:
- Implement PEP 378, Format Specifier for Thousands Separator, for
floats, ints, and longs.
- Issue #5515: 'n' formatting for ints, longs, and floats handles
leading zero formatting poorly.
- Issue #5772: For float.__format__, don't add a trailing ".0" if
we're using no type code and we have an exponent.
For simple uses for str.format(), this makes the typing easier. Hopfully this
will help in the adoption of str.format().
For example:
'The {} is {}'.format('sky', 'blue')
You can mix and matcth auto-numbering and named replacement fields:
'The {} is {color}'.format('sky', color='blue')
But you can't mix and match auto-numbering and specified numbering:
'The {0} is {}'.format('sky', 'blue')
ValueError: cannot switch from manual field specification to automatic field numbering
Will port to 3.1.
* crashes on memory allocation failure found with failmalloc
* memory leaks found with valgrind
* compiler warnings in opt mode which would lead to invalid memory reads
* problem using wrong name in decimal module reported by pychecker
Update the valgrind suppressions file with new leaks that are small/one-time
leaks we don't care about (ie, they are too hard to fix).
TBR=barry
TESTED=./python -E -tt ./Lib/test/regrtest.py -uall (both debug and opt modes)
in opt mode:
valgrind -q --leak-check=yes --suppressions=Misc/valgrind-python.supp \
./python -E -tt ./Lib/test/regrtest.py -uall,-bsddb,-compiler \
-x test_logging test_ssl test_multiprocessing
valgrind -q --leak-check=yes --suppressions=Misc/valgrind-python.supp \
./python -E -tt ./Lib/test/regrtest.py test_multiprocessing
for i in `seq 1 4000` ; do
LD_PRELOAD=~/local/lib/libfailmalloc.so FAILMALLOC_INTERVAL=$i \
./python -c pass
done
At least some of these fixes should probably be backported to 2.5.
Optimization of str.format() for cases with str, unicode, int, long,
and float arguments. This gives about 30% speed improvement for the
simplest (but most common) cases. This patch skips the __format__
dispatch, and also avoids creating an object to hold the format_spec.
Unfortunately there's a complication in 2.6 with int, long, and float
because they always expect str format_specs. So in the unicode
version of this optimization, just check for unicode objects. int,
float, long, and str can be added later, if needed.
Adds 'n' as a format specifier for integers, to mirror the same
specifier which is already available for floats. 'n' is the same as
'd', but inserts the current locale-specific thousands grouping.
I added this as a stringlib function, but it's only used by str type,
not unicode. This is because of an implementation detail in
unicode.format(), which does its own str->unicode conversion. But the
unicode version will be needed in 3.0, and it may be needed by other
code eventually in 2.6 (maybe decimal?), so I left it as a stringlib
implementation. As long as the unicode version isn't instantiated,
there's no overhead for this.