| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
(fixes bug #1119418)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for xrange and list objects).
* list.__reversed__ now checks the length of the sequence object before
calling PyList_GET_ITEM() because the mutable could have changed length.
* all three implementations are now tranparent with respect to length and
maintain the invariant len(it) == len(list(it)) even when the underlying
sequence mutates.
* __builtin__.reversed() now frees the underlying sequence as soon
as the iterator is exhausted.
* the code paths were rearranged so that the most common paths
do not require a jump.
|
| | |
|
| |
|
|
|
|
| |
to more accurately describe what the function does.
Suggested by Thomas Wouters.
|
| |
|
|
| |
Factors out the common case of returning self.
|
| | |
|
| |
|
|
|
| |
dir(xrange(10))
xrange(10).__getitem__(4)
|
| |
|
|
|
|
|
|
|
|
| |
but returns r->len which is a long. This doesn't even cause a warning
on 32-bit platforms, but can return bogus values on 64-bit platforms
(and should cause a compiler warning). Fix this by inserting a range
check when LONG_MAX != INT_MAX, and adding an explicit cast to (int)
when the test passes. When r->len is out of range, PySequence_Size()
and hence len() will report an error (but an iterator will still
work).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The staticforward define was needed to support certain broken C
compilers (notably SCO ODT 3.0, perhaps early AIX as well) botched the
static keyword when it was used with a forward declaration of a static
initialized structure. Standard C allows the forward declaration with
static, and we've decided to stop catering to broken C compilers. (In
fact, we expect that the compilers are all fixed eight years later.)
I'm leaving staticforward and statichere defined in object.h as
static. This is only for backwards compatibility with C extensions
that might still use it.
XXX I haven't updated the documentation.
|
| |
|
|
|
|
| |
PyType_Ready() because the tp_iternext slot is set. Also removed the
redundant (and expensive!) call to raise StopIteration from
rangeiter_next().
|
| | |
|
| | |
|
| |
|
|
|
| |
Also, added more regression tests to cover the new type and test its
conformity with range().
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
handlers were both set, but were not compatible. This change uses only the
tp_getattro handler with a more "modern" approach.
This fixes SF bug #551285.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
result would overflow an int. Check for this. (SF bug #488482, Armin
Rigo.)
|
| |
|
|
|
|
| |
into a hardcoded char* buffer.
Closes patch #454743.
|
| | |
|
| | |
|
| |
|
|
|
| |
on python-dev. The features will still vanish, however, just one release
later.
|
| |
|
|
|
| |
contains, tolist(), and the start/stop/step attributes. This includes
removing the 4th ('repeat') argument to PyRange_New().
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
object.
This fixes potential overflows in xrange()'s internal calculations on
64-bit platforms. The fix is complicated because the sq_length slot
function can only return an int; we want to support
xrange(sys.maxint), which is a 64-bit quantity on most 64-bit
platforms (except Win64). The solution is hacky but the best
possible: when the range is that long, we can use it in a for loop but
we can't ask for its length (nor can we actually iterate beyond
2**31-1, because the sq_item slot function has the same restrictions
on its arguments. Fixing those restrictions is a project for another
day...
|
| | |
|
| |
|
|
|
|
|
| |
*really* closes bug #121965.
Added three attributes to the xrange object: start, stop, and step. These
are the same as for the slice objects.
|
| |
|
|
|
|
| |
where ">=" should have been.
This closes bug #121965.
|
| |
|
|
| |
This should match the situation in the 1.6b1 tree.
|
| |
|
|
| |
Ensure that # of args to sprintf always matches # of format specifiers.
|
| |
|
|
| |
snprintf() is available.
|
| |
|
|
|
| |
Revise the tp_repr handler to produce a more "minimal" presentation.
Make the tolist() method use PyArg_ParseTuple() and provide a docstring.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following patch adds "sq_contains" support to rangeobject, and enables
the already-written support for sq_contains in listobject and tupleobject.
The rangeobject "contains" code should be a bit more efficient than the
current default "in" implementation ;-) It might not get used much, but it's
not that much to add.
listobject.c and tupleobject.c already had code for sq_contains, and the
proper struct member was set, but the PyType structure was not extended to
include tp_flags, so the object-specific code was not getting called (Go
ahead, test it ;-). I also did this for the immutable_list_type in
listobject.c, eventhough it is probably never used. Symmetry and all that.
|
| |
|
|
|
|
|
|
|
|
| |
For more comments, read the patches@python.org archives.
For documentation read the comments in mymalloc.h and objimpl.h.
(This is not exactly what Vladimir posted to the patches list; I've
made a few changes, and Vladimir sent me a fix in private email for a
problem that only occurs in debug mode. I'm also holding back on his
change to main.c, which seems unnecessary to me.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
