| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
svn+ssh://pythondev@svn.python.org/python/branches/py3k
........
r86596 | ezio.melotti | 2010-11-20 21:04:17 +0200 (Sat, 20 Nov 2010) | 1 line
#9424: Replace deprecated assert* methods in the Python test suite.
........
|
| | |
|
| |
|
|
|
|
| |
to integer PyArg_Parse* format codes into a TypeError. Add a
DeprecationWarning for floats passed with the 'L' format code, which
didn't previously have a warning.
|
| |
|
|
|
|
| |
xrange tests to cover some special cases that caused problems
in py3k. This is a partial backport of r76292-76293 (see
issue #7298.)
|
| | |
|
| | |
|
| |
|
|
| |
Cleaned up the unit test.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
least as big as a long. I believe this to be a safe assumption that is being
made in many parts of CPython, but a check could be added.
len(xrange(sys.maxint)) works now, so fix the testsuite's odd exception for
64-bit platforms too. It also fixes 'zip(xrange(sys.maxint), it)' as a
portable-ish (if expensive) alternative to enumerate(it); since zip() now
calls len(), this was breaking on (real) 64-bit platforms. No additional
test was added for that behaviour.
|
| |
|
|
| |
rangeobject.c has an #ifdef that is reached only when LONG_MAX != INT_MAX
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added XXX comment about why the undocumented PyRange_New() API function
is too broken to be worth the considerable pain of repairing.
Changed range_new() to stop using PyRange_New(). This fixes a variety
of bogus errors. Nothing in the core uses PyRange_New() now.
Documented that xrange() is intended to be simple and fast, and that
CPython restricts its arguments, and length of its result sequence, to
native C longs.
Added some tests that failed before the patch, and repaired a test that
relied on a bogus OverflowError getting raised.
|
| |
|
