| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
failure when running ./python -m test.regrtest -R 3:2: test_format
|
| | |
|
| |
|
|
| |
which is no longer needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks Gabriel Genellina.
|
| |
|
|
| |
with %G.
|
| |
|
|
| |
overflow on x64. Now the testsuite is well behaved on that platform.
|
| | |
|
| |
|
|
|
|
| |
__oct__, __hex__ don't return a string.
Klocwork 308
|
| |
|
|
| |
2**32-1 makes no sense. Use 2**31-1 instead.
|
| |
|
|
|
|
|
|
|
|
| |
and left shifts. (Thanks to Kalle Svensson for SF patch 849227.)
This addresses most of the remaining semantic changes promised by
PEP 237, except for repr() of a long, which still shows the trailing
'L'. The PEP appears to promise warnings for operations that
changed semantics compared to Python 2.3, but this is not
implemented; we've suffered through enough warnings related to
hex/oct literals and I think it's best to be silent now.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When mwh added extended slicing, strings and unicode became mappings.
Thus, dict was set which prevented an error when doing:
newstr = 'format without a percent' % string_value
This fix raises an exception again when there are no formats
and % with a string value.
|
| |
|
|
|
| |
Only runs when sys.maxint == 2**32 - 1; different things go wrong
on a 64-bit box.
|
| | |
|
| |
|
|
|
|
|
|
| |
'%g' % '1'
'%d' % '1'
Add a test for these conditions
Fix the test so that if not exception is raise, this is a failure
|
| |
|
|
|
|
|
|
|
|
|
| |
imports e.g. test_support must do so using an absolute package name
such as "import test.test_support" or "from test import test_support".
This also updates the README in Lib/test, and gets rid of the
duplicate data dirctory in Lib/test/data (replaced by
Lib/email/test/data).
Now Tim and Jack can have at it. :)
|
| | |
|
| |
|
|
|
|
|
|
| |
- Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled
- check for Py_USING_UNICODE in all places that use Unicode functions
- disables unicode literals, and the builtin functions
- add the types.StringTypes list
- remove Unicode literals from most tests.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
"%#x" % 0
blew up, at heart because C sprintf supplies a base marker if and only if
the value is not 0. I then fixed that, by tolerating C's inconsistency
when it does %#x, and taking away that *Python* produced 0x0 when
formatting 0L (the "long" flavor of 0) under %#x itself. But after talking
with Guido, we agreed it would be better to supply 0x for the short int
case too, despite that it's inconsistent with C, because C is inconsistent
with itself and with Python's hex(0) (plus, while "%#x" % 0 didn't work
before, "%#x" % 0L *did*, and returned "0x0"). Similarly for %#X conversion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
http://sourceforge.net/tracker/index.php?func=detail&aid=415514&group_id=5470&atid=105470
For short ints, Python defers to the platform C library to figure out what
%#x should do. The code asserted that the platform C returned a string
beginning with "0x". However, that's not true when-- and only when --the
*value* being formatted is 0. Changed the code to live with C's inconsistency
here. In the meantime, the problem does not arise if you format a long 0 (0L)
instead. However, that's because the code *we* wrote to do %#x conversions on
longs produces a leading "0x" regardless of value. That's probably wrong too:
we should drop leading "0x", for consistency with C, when (& only when) formatting
0L. So I changed the long formatting code to do that too.
|
| |
|
|
| |
(This one was trivial -- no actual string. references in it!)
|
| | |
|
| |
|
|
| |
'verify' iff it's used by a test module...
|
| |
|
|
|
|
|
| |
and replaces them with a new API verify(). As a result the regression
suite will also perform its tests in optimization mode.
Written by Marc-Andre Lemburg. Copyright assigned to Guido van Rossum.
|
| | |
|
| |
|
|
| |
(Oh, look, it adds another little utility function for testing)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
%d,i,u,x,X,o formats.
Note a curious extension to the std C rules: x, X and o formatting can never produce
a sign character in C, so the '+' and ' ' flags are meaningless for them. But
unbounded ints *can* produce a sign character under these conversions (no fixed-
width bitstring is wide enough to hold all negative values in 2's-comp form). So
these flags become meaningful in Python when formatting a Python long which is too
big to fit in a C long. This required shuffling around existing code, which hacked
x and X conversions to death when both the '#' and '0' flags were specified: the
hacks weren't strong enough to deal with the simultaneous possibility of the ' ' or
'+' flags too, since signs were always meaningless before for x and X conversions.
Isomorphic shuffling was required in unicodeobject.c.
Also added dozens of non-trivial new unbounded-int test cases to test_format.py.
|
|
|
New test for huge formatting strings (these could cause core
dumps in previous versions).
By Trent Mick.
|
