summaryrefslogtreecommitdiffstats
path: root/Objects/rangeobject.c
Commit message (Collapse)AuthorAgeFilesLines
* consistently use Py_TYPE, Py_REFCNT, and correct initializer macros (#3563)Benjamin Peterson2017-09-141-4/+2
| | | This no-op change makes 2.7 more consistent with 3.x to ease comparison and backports.
* Issue #28139: Fix messed up indentationMartin Panter2016-09-171-3/+3
| | | | | Also update the classmethod and staticmethod doc strings and comments to match the RST documentation.
* Issue #14783: Backport changes from 3.2.Chris Jerdonek2012-10-081-1/+2
|
* Issues #16029, #16030: Fix pickling and repr of large xranges.Mark Dickinson2012-09-281-5/+29
|
* Untabify C files. Will watch buildbots.Antoine Pitrou2010-05-091-210/+210
|
* Silence MSVC warning about unary minus applied to unsigned type.Mark Dickinson2009-11-161-1/+1
|
* Avoid signed overflow in some xrange calculations, and extendMark Dickinson2009-11-151-34/+44
| | | | | | xrange tests to cover some special cases that caused problems in py3k. This is a partial backport of r76292-76293 (see issue #7298.)
* Added better pickling support to xrange objects.Alexandre Vassalotti2008-06-101-3/+3
| | | | Cleaned up the unit test.
* Issue 2582: Fix pickling of xrange objects.Alexandre Vassalotti2008-06-101-0/+11
|
* This reverts r63675 based on the discussion in this thread:Gregory P. Smith2008-06-091-3/+3
| | | | | | | http://mail.python.org/pipermail/python-dev/2008-June/079988.html Python 2.6 should stick with PyString_* in its codebase. The PyBytes_* names in the spirit of 3.0 are available via a #define only. See the email thread.
* Renamed PyString to PyBytesChristian Heimes2008-05-261-3/+3
|
* Remove unnecessary modulo division.Raymond Hettinger2008-02-081-1/+1
| | | | The preceding test guarantees that 0 <= i < len.
* Remove "static forward" declaration. Move constructorsMartin v. Löwis2006-04-111-47/+45
| | | | after the type objects.
* Make xrange more Py_ssize_t aware, by assuming a Py_ssize_t is always atThomas Wouters2006-04-041-7/+0
| | | | | | | | | | | 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.
* Remove unnecessary casts in type object initializers.Georg Brandl2006-03-301-38/+38
|
* Merge ssize_t branch.Martin v. Löwis2006-02-151-7/+7
|
* Renamed _length_cue() to __length_hint__(). See:Armin Rigo2006-02-111-2/+2
| | | | http://mail.python.org/pipermail/python-dev/2006-February/060524.html
* Convert iterator __len__() methods to a private API.Raymond Hettinger2005-09-241-8/+10
|
* Disallow keyword arguments for type constructors that don't use them.Georg Brandl2005-08-261-0/+3
| | | | (fixes bug #1119418)
* Remove PyRange_New().Raymond Hettinger2004-12-031-45/+0
|
* Bug 1003935: xrange overflowsTim Peters2004-08-081-1/+16
| | | | | | | | | | | | | | | 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.
* Trimmed trailing whitespace.Tim Peters2004-08-081-5/+5
|
* Add a missing decref.Michael W. Hudson2004-08-021-0/+1
|
* Tidied up the implementations of reversed (including the custom onesRaymond Hettinger2004-03-101-1/+13
| | | | | | | | | | | | | | | | | 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.
* Implement and apply PEP 322, reverse iterationRaymond Hettinger2003-11-061-1/+36
|
* Renamed PyObject_GenericGetIter to PyObject_SelfIterRaymond Hettinger2003-03-171-1/+1
| | | | | | to more accurately describe what the function does. Suggested by Thomas Wouters.
* Created PyObject_GenericGetIter().Raymond Hettinger2003-03-171-8/+1
| | | | Factors out the common case of returning self.
* Update comments about the performance of xrange().Raymond Hettinger2002-12-111-2/+2
|
* Restore attribute access so that the following work again:Raymond Hettinger2002-11-071-1/+1
| | | | | dir(xrange(10)) xrange(10).__getitem__(4)
* Untested code for 64-bit platforms. range_length() is declared as intGuido van Rossum2002-09-111-1/+8
| | | | | | | | | | 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).
* staticforward bites the dust.Jeremy Hylton2002-07-171-2/+2
| | | | | | | | | | | | | | | 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.
* Remove the next() method -- one is supplied automatically byGuido van Rossum2002-07-161-10/+1
| | | | | | PyType_Ready() because the tp_iternext slot is set. Also removed the redundant (and expensive!) call to raise StopIteration from rangeiter_next().
* Patch #568124: Add doc string macros.Martin v. Löwis2002-06-131-2/+2
|
* Pyrangeiter_Type && range_iter should be staticNeal Norwitz2002-06-061-5/+5
|
* Skip Montanaro's patch, SF 559833, exposing xrange type in builtins.Raymond Hettinger2002-06-051-2/+84
| | | | | Also, added more regression tests to cover the new type and test its conformity with range().
* SF 564601 adding rangeiterobject to make xrange() iterate like range().Raymond Hettinger2002-06-051-46/+91
|
* Inverted test for small speedupRaymond Hettinger2002-06-041-5/+4
|
* Patch #551410: Implement tp_getiter.Martin v. Löwis2002-05-081-1/+51
|
* Remove old deprecated features from the xrange object.Fred Drake2002-05-021-273/+40
|
* Fix attribute access for the xrange objects. The tp_getattr and tp_getattroFred Drake2002-05-021-31/+38
| | | | | | 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.
* Remove PyMalloc_New and PyMalloc_Del.Neil Schemenauer2002-04-121-2/+2
|
* Use pymalloc if it's enabled.Neil Schemenauer2002-03-221-2/+2
|
* Fix spelling mistakes. Bugfix candidates.Neal Norwitz2002-01-291-1/+1
|
* long_mul(): The PyNumber_Multiply() call can return a long if theGuido van Rossum2001-12-041-0/+6
| | | | | result would overflow an int. Check for this. (SF bug #488482, Armin Rigo.)
* repr's converted to using PyString_FromFormat() instead of sprintf'ingBarry Warsaw2001-08-241-19/+19
| | | | | | into a hardcoded char* buffer. Closes patch #454743.
* Patch #427190: Implement and use METH_NOARGS and METH_O.Martin v. Löwis2001-08-161-4/+1
|
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-16/+28
|
* Re-add 'advanced' xrange features, adding DeprecationWarnings as discussedThomas Wouters2001-07-091-16/+219
| | | | | on python-dev. The features will still vanish, however, just one release later.
* Rip out the fancy behaviors of xrange that nobody uses: repeat, slice,Guido van Rossum2001-07-051-222/+15
| | | | | contains, tolist(), and the start/stop/step attributes. This includes removing the 4th ('repeat') argument to PyRange_New().
* SF patch #103158 by Greg Ball: Don't do unsafe arithmetic in xrangeGuido van Rossum2001-01-151-10/+80
| | | | | | | | | | | | | | | 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...
generated by cgit v0.12 at 2025-08-28 19:10:37 (GMT)