| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
modules
|
| |
|
|
|
|
|
|
|
|
|
|
| |
round included:
* Revert round to its 2.6 behavior (half away from 0).
* Because round, floor, and ceil always return float again, it's no
longer necessary to have them delegate to __xxx___, so I've ripped
that out of their implementations and the Real ABC. This also helps
in implementing types that work in both 2.6 and 3.0: you return int
from the __xxx__ methods, and let it get enabled by the version
upgrade.
* Make pow(-1, .5) raise a ValueError again.
|
| | |
|
| |
|
|
|
|
|
| |
the complex_pow part), r56649, r56652, r56715, r57296, r57302, r57359, r57361,
r57372, r57738, r57739, r58017, r58039, r58040, and r59390, and new
documentation. The only significant difference is that round(x) returns a float
to preserve backward-compatibility. See http://bugs.python.org/issue1689.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* unified the way intobject, longobject and mystrtoul handle
values around -sys.maxint-1.
* in general, trying to entierely avoid overflows in any computation
involving signed ints or longs is extremely involved. Fixed a few
simple cases where a compiler might be too clever (but that's all
guesswork).
* more overflow checks against bad data in marshal.c.
* 2.5 specific: fixed a number of places that were still confusing int
and Py_ssize_t. Some of them could potentially have caused
"real-world" breakage.
* list.pop(x): fixing overflow issues on x was messy. I just reverted
to PyArg_ParseTuple("n"), which does the right thing. (An obscure
test was trying to give a Decimal to list.pop()... doesn't make
sense any more IMHO)
* trying to write a few tests...
|
| |
|
|
| |
Hex longs now print with lowercase letters like their int counterparts.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an integer is compared to a float now, the int isn't coerced to float.
This avoids spurious overflow exceptions and insane results. This should
compute correct results, without raising spurious exceptions, in all cases
now -- although I expect that what happens when an int/long is compared to
a NaN is still a platform accident.
Note that we had potential problems here even with "short" ints, on boxes
where sizeof(long)==8. There's #ifdef'ed code here to handle that, but
I can't test it as intended. I tested it by changing the #ifdef to
trigger on my 32-bit box instead.
I suppose this is a bugfix candidate, but I won't backport it. It's
long-winded (for speed) and messy (because the problem is messy). Note
that this also depends on a previous 2.4 patch that introduced
_Py_SwappedOp[] as an extern.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
huge. On older Linux systems, the C library's strtod() apparently
gives up before seeing the end of the string when it sees so many
digits that it thinks the result must be Infinity. (It is wrong, BTW
-- there could be an "e-10000" hiding behind 10,000 digits.) The
shorter shuge still tests what it's testing, without relying on
strtod() doing a super job.
|
| |
|
|
| |
Check return value of PyLong_AsDouble(), it can return an error.
|
| |
|
|
|
|
|
| |
that is outside the integer range no longer raises OverflowError, but
returns a long object instead.
This fixes SF bug http://www.python.org/sf/635115
|
| |
|
|
| |
runtime.
|
| |
|
|
| |
"lopsided Karatsuba" driver also gets some exercise.
|
| |
|
|
|
|
| |
test was written. So boosted the number of "digits" this generates, and
also beefed up the "* / divmod" test to tickle numbers big enough to
trigger the Karatsuba algorithm. It takes about 2 seconds now on my box.
|
| |
|
|
|
|
|
|
|
|
|
| |
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. :)
|
| | |
|
| |
|
|
|
|
| |
getting Infs, NaNs, or nonsense in 2.1 and before; in yesterday's CVS we
were getting OverflowError; but these functions always make good sense
for positive arguments, no matter how large).
|
| |
|
|
|
|
| |
"/" and "//", and doesn't really care what they *mean*, just that both
are tried (and that, whatever they mean, they act similarly for int and
long arguments).
|
| |
|
|
|
| |
mostly changes of / operators into //. Once or twice I did more or
less than recommended.
|
| | |
|
| |
|
|
|
|
|
| |
the fiddling is simply due to that no caller of PyLong_AsDouble ever
checked for failure (so that's fixing old bugs). PyLong_AsDouble is much
faster for big inputs now too, but that's more of a happy consequence
than a design goal.
|
| |
|
|
|
| |
integer types, and y must be >= 0. See discussion at
http://sf.net/tracker/index.php?func=detail&aid=457066&group_id=5470&atid=105470
|
| | |
|
| |
|
|
|
| |
Added tests for boundary cases in magical PEP 237 int->long auto-overflow,
but nothing here addresses the rest of the bug report so left it open.
|
| | |
|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
[The test is in a slightly odd place, in test_division_2; but it
exercises the recent change to long_mult(), and that's all we really
ask for. --GvR]
|
| | |
|
| | |
|
| |
|
