summaryrefslogtreecommitdiff
path: root/Objects/sliceobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Recorded merge of revisions 81029 via svnmerge fromAntoine Pitrou2010-05-091-235/+235
| | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r81029 | antoine.pitrou | 2010-05-09 16:46:46 +0200 (dim., 09 mai 2010) | 3 lines Untabify C files. Will watch buildbots. ........
* Merged revisions 71734,71738-71739 via svnmerge fromBenjamin Peterson2009-04-201-1/+1
| | | | | | | | | | | | | | | | | | svn+ssh://pythondev@svn.python.org/python/trunk ........ r71734 | benjamin.peterson | 2009-04-18 17:15:26 -0500 (Sat, 18 Apr 2009) | 1 line many more types to initialize (I had to expose some of them) ........ r71738 | benjamin.peterson | 2009-04-18 21:32:42 -0500 (Sat, 18 Apr 2009) | 1 line initialize weakref some weakref types ........ r71739 | benjamin.peterson | 2009-04-18 21:40:43 -0500 (Sat, 18 Apr 2009) | 1 line make errors consistent ........
* Issue #3004: Minor fix to slice.indices(). slice(-10).indices(9) nowMark Dickinson2008-06-201-2/+3
| | | | | returns (0, 0, 1) instead of (0, -1, 1), and slice(None, 10, -1).indices(10) returns (9, 9, -1) instead of (9, 10, -1).
* This reverts r63675 based on the discussion in this thread:Gregory P. Smith2008-06-091-9/+9
| | | | | | | 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-9/+9
|
* #1629: Renamed Py_Size, Py_Type and Py_Refcnt to Py_SIZE, Py_TYPE and ↵Christian Heimes2007-12-191-1/+1
| | | | Py_REFCNT. Macros for b/w compatibility are available.
* PEP 3123: Provide forward compatibility with Python 3.0, while keepingMartin v. Löwis2007-07-211-6/+5
| | | | | backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and PyVarObject_HEAD_INIT.
* SF 1191699: Make slices picklableRaymond Hettinger2007-04-111-0/+10
|
* Patch #1538606, Patch to fix __index__() clipping.Neal Norwitz2006-08-121-1/+1
| | | | | | | I modified this patch some by fixing style, some error checking, and adding XXX comments. This patch requires review and some changes are to be expected. I'm checking in now to get the greatest possible review and establish a baseline for moving forward. I don't want this to hold up release if possible.
* Allow long integers in PySlice_GetIndices.Martin v. Löwis2006-04-031-3/+3
|
* Use Py_ssize_t in slicesNeal Norwitz2006-04-031-5/+5
|
* Remove unnecessary casts in type object initializers.Georg Brandl2006-03-301-20/+20
|
* Stop duplicating code and handle slice indices consistently and correctlyNeal Norwitz2006-03-231-0/+19
| | | | wrt to ssize_t.
* Merge ssize_t branch.Martin v. Löwis2006-02-151-6/+7
|
* Disallow keyword arguments for type constructors that don't use them.Georg Brandl2005-08-261-0/+3
| | | | (fixes bug #1119418)
* SF bug #800796: Difference between hash() and __hash__()Raymond Hettinger2003-09-051-1/+8
| | | | slice(5).__hash__() now raises a TypeError.
* SF patch #659536: Use PyArg_UnpackTuple where possible.Raymond Hettinger2002-12-291-1/+1
| | | | | | | Obtain cleaner coding and a system wide performance boost by using the fast, pre-parsed PyArg_Unpack function instead of PyArg_ParseTuple function which is driven by a format string.
* Handle really big steps in extended slices.Michael W. Hudson2002-11-061-5/+2
| | | | Fixes a test failure on 64 bit platforms (I hope).
* Some days, I think my comment ofMichael W. Hudson2002-11-051-6/+12
| | | | | | | | | | | | /* this is harder to get right than you might think */ angered some God somewhere. After noticing >>> range(5000000)[slice(96360, None, 439)] [] I found that my cute test for the slice being empty failed due to overflow. Fixed, and added simple test (not the above!).
* Fix for platforms where int != long.Michael W. Hudson2002-09-121-1/+1
|
* Silly typo. Not sure how that got in.Michael W. Hudson2002-07-191-1/+1
|
* A few days ago, Guido said (in the thread "[Python-Dev] PythonMichael W. Hudson2002-07-191-1/+34
| | | | | | | | version of PySlice_GetIndicesEx"): > OK. Michael, if you want to check in indices(), go ahead. Then I did what was needed, but didn't check it in. Here it is.
* SF patch 568629 by Oren Tirosh: types made callable.Guido van Rossum2002-06-141-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These built-in functions are replaced by their (now callable) type: slice() buffer() and these types can also be called (but have no built-in named function named after them) classobj (type name used to be "class") code function instance instancemethod (type name used to be "instance method") The module "new" has been replaced with a small backward compatibility placeholder in Python. A large portion of the patch simply removes the new module from various platform-specific build recipes. The following binary Mac project files still have references to it: Mac/Build/PythonCore.mcp Mac/Build/PythonStandSmall.mcp Mac/Build/PythonStandalone.mcp [I've tweaked the code layout and the doc strings here and there, and added a comment to types.py about StringTypes vs. basestring. --Guido]
* Fix for problem reported by Neal Norwitz. Tighten up calculation ofMichael W. Hudson2002-06-111-3/+5
| | | | slicelength. Include his test case.
* This is my nearly two year old patchMichael W. Hudson2002-06-111-0/+53
| | | | | | | | | [ 400998 ] experimental support for extended slicing on lists somewhat spruced up and better tested than it was when I wrote it. Includes docs & tests. The whatsnew section needs expanding, and arrays should support extended slices -- later.
* Remove PyMalloc_New and PyMalloc_Del.Neil Schemenauer2002-04-121-2/+2
|
* Use pymalloc if it's enabled.Neil Schemenauer2002-03-221-2/+2
|
* Add values to tp_getattro and tp_flags so that dir(Ellipsis) willGuido van Rossum2001-10-301-14/+20
| | | | return the same as dir(None).
* Add optional docstrings to member descriptors. For backwardsGuido van Rossum2001-09-201-1/+1
| | | | | | | | | | | | | | | compatibility, this required all places where an array of "struct memberlist" structures was declared that is referenced from a type's tp_members slot to change the type of the structure to PyMemberDef; "struct memberlist" is now only used by old code that still calls PyMember_Get/Set. The code in PyObject_GenericGetAttr/SetAttr now calls the new APIs PyMember_GetOne/SetOne, which take a PyMemberDef argument. As examples, I added actual docstrings to the attributes of a few types: file, complex, instance method, super, and xxsubtype.spamlist. Also converted the symtable to new style getattr.
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-35/+35
|
* SF patch #408326 by Robin Thomas: slice objects comparable, notGuido van Rossum2001-03-201-3/+23
| | | | | | | | | | | | | | | | | | hashable This patch changes the behavior of slice objects in the following manner: - Slice objects are now comparable with other slice objects as though they were logically tuples of (start,stop,step). The tuple is not created in the comparison function, but the comparison behavior is logically equivalent. - Slice objects are not hashable. With the above change to being comparable, slice objects now cannot be used as keys in dictionaries. [I've edited the patch for style. Note that this fixes the problem that dict[i:j] seemed to work but was meaningless. --GvR]
* Test for NULL returned from PyObject_NEW().Guido van Rossum2000-12-141-0/+3
|
* ANSI-fication of the sources.Fred Drake2000-07-091-19/+7
|
* Vladimir Marangozov's long-awaited malloc restructuring.Guido van Rossum2000-05-031-3/+2
| | | | | | | | | | 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.)
* Ellipses -> Ellipsis rename (the dictionary really says that it shouldGuido van Rossum1996-10-111-9/+9
| | | | | | | | be Ellipsis!). Bumped the API version because a linker-visible symbol is affected. Old C code will still compile -- there's a b/w compat macro. Similarly, old Python code will still run, builtin exports both Ellipses and Ellipsis.
* repr("...") -> "Ellipses"Guido van Rossum1996-07-301-1/+1
|
* Added sliceobject.cGuido van Rossum1996-07-301-0/+184