summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* Fix typo found by Neal Norwitz.Raymond Hettinger2003-10-161-1/+1
|
* * list.sort() now supports three keyword arguments: cmp, key, and reverse.Raymond Hettinger2003-10-161-5/+228
| | | | | | | key provides C support for the decorate-sort-undecorate pattern. reverse provide a stable sort of the list with the comparisions reversed. * Amended the docs to guarantee sort stability.
* Simplify and speedup uses of Py_BuildValue():Raymond Hettinger2003-10-124-29/+28
| | | | | | * Py_BuildValue("(OOO)",a,b,c) --> PyTuple_Pack(3,a,b,c) * Py_BuildValue("()",a) --> PyTuple_New(0) * Py_BuildValue("O", a) --> Py_INCREF(a)
* Extended tuple's C API to include a new function, PyTuple_Pack() that isRaymond Hettinger2003-10-121-0/+22
| | | | | useful for rapidly building argument tuples without having to invoke the more sophisticated machinery of Py_BuildValue().
* Use the simpler and faster PyArg_UnpackTuple() instead ofRaymond Hettinger2003-10-111-24/+24
| | | | PyArg_ParseTuple() where possible.
* SF bug #820397: __nonzero__() returns 1/0Raymond Hettinger2003-10-111-1/+15
| | | | | | Altered to return a PyBool instead of a PyInt. Backport candidate.
* Return a bool rather than an int from proxy_has_key().Guido van Rossum2003-10-091-1/+4
|
* Fix leak introduced by previous typeobject.c checkin.Guido van Rossum2003-10-091-4/+3
|
* SF patch #820195 by Wojtek Walczak (gminick at users.sourceforge.net):Guido van Rossum2003-10-081-2/+4
| | | | make obj.__contains__() returns True/False instead of 1/0.
* Fix for SF bug [ 817156 ] invalid \U escape gives 0=length unistr.Jeremy Hylton2003-10-061-1/+1
|
* On c.l.py, Martin v. Löwis said that Py_UNICODE could be of a signed type,Tim Peters2003-09-161-137/+145
| | | | | | | so fiddle Jeremy's fix to live with that. Also added more comments. Bugfix candidate (this bug is in all versions of Python, at least since 2.1).
* Double-fix of crash in Unicode freelist handling.Jeremy Hylton2003-09-161-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | If a length-1 Unicode string was in the freelist and it was uninitialized or pointed to a very large (magnitude) negative number, the check unicode_latin1[unicode->str[0]] == unicode could cause a segmentation violation, e.g. unicode->str[0] is 0xcbcbcbcb. Fix this in two ways: 1. Change guard befor unicode_latin1[] to test against 256U. If I understand correctly, the unsigned long used to store UCS4 on my box was getting converted to a signed long to compare with the signed constant 256. 2. Change _PyUnicode_New() to make sure the first element of str is always initialized to zero. There are several places in the code where the caller can exit with an error before initializing any of str, which would leave junk in str[0]. Also, silence a compiler warning on pointer vs. int arithmetic. Bug fix candidate.
* Fix leak in classobject.c. The leak surfaced on the error exit whenRaymond Hettinger2003-09-161-0/+1
| | | | | hashing a class that does not define __hash__ but does define a comparison.
* Change checks of PyUnicode_Resize() return value for clarity.Jeremy Hylton2003-09-161-18/+17
| | | | | | | The unicode_resize() family only returns -1 or 0 so simply checking for != 0 is sufficient, but somewhat unclear. Many Python API functions return < 0 on error, reserving the right to return 0 or 1 on success. Change the call sites for consistency with these calls.
* Only release buffer after file has been closed. Fixes #800824.Martin v. Löwis2003-09-071-1/+1
| | | | Will backport to 2.2.
* SF bug 801631: file.truncate fault on windows.Tim Peters2003-09-071-74/+66
| | | | | | | | | | | | | | | | | file_truncate(): C doesn't define what fflush(fp) does if fp is open for update, and the preceding I/O operation on fp was input. On Windows, fflush() actually changes the current file position then. Because Windows doesn't support ftruncate() directly, this not only caused Python's file.truncate() to change the file position (contra our docs), it also caused the file not to change size. Repaired by getting the initial file position at the start, restoring it at the end, and tossing all the complicated micro-efficiency checks trying to avoid "provably unnecessary" seeks. file.truncate() can't be a frequent operation, and seeking to the current file position has got to be cheap anyway. Bugfix candidate.
* SF bug #800796: Difference between hash() and __hash__()Raymond Hettinger2003-09-051-1/+8
| | | | slice(5).__hash__() now raises a TypeError.
* Patch #788249: Pass an explicit buffer to setvbuf in PyFile_SetBufSize().Martin v. Löwis2003-09-041-5/+19
| | | | Fixes #603724. Will backport to 2.3.
* SF patch #798467: Update docstring of has_key for bool changesRaymond Hettinger2003-09-012-2/+2
| | | | (Contributed by George Yoshida.)
* Remove 'e.g.' from error messageRaymond Hettinger2003-08-301-3/+3
|
* SF bug #795506: Wrong handling of string format code for float values.Raymond Hettinger2003-08-272-0/+6
| | | | | | Adding missing support for '%F'. Will backport to 2.3.1.
* Fix SF #789402, Memory leak on open()Neal Norwitz2003-08-151-0/+1
| | | | If opening a directory, the exception would leak.
* Fix refcounting leak in charmaptranslate_lookup()Walter Dörwald2003-08-151-0/+1
|
* Fix another refcounting leak in PyUnicode_EncodeCharmap().Walter Dörwald2003-08-151-1/+3
|
* Fix another refcounting leak (in PyUnicode_DecodeUnicodeEscape()).Walter Dörwald2003-08-151-0/+2
|
* Fix forMichael W. Hudson2003-08-152-5/+17
| | | | | | | | | [ 784825 ] fix obscure crash in descriptor handling Should be applied to release23-maint and in all likelyhood release22-maint, too. Certainly doesn't apply to release21-maint.
* My last fix left n used unitialized in tha a==b case.Michael W. Hudson2003-08-151-1/+1
| | | | | | Fix, by not using n at all in that case. Needs to be applied to release23-maint, too.
* complex_new(): This could leak when the argument was neither string norTim Peters2003-08-151-0/+3
| | | | | | number. This accounts for the 2 refcount leaks per test_complex run Michael Hudson discovered (I figured only I would have the stomach to look for leaks in floating-point code <wink>).
* Fix refcount leak in PyUnicode_EncodeCharmap(). The bug surfacesWalter Dörwald2003-08-141-3/+3
| | | | | | | | | | when an encoding error occurs and the callback name is unknown, i.e. when the callback has to be called. The problem was that the fact that the callback has already been looked up was only recorded in a local variable in charmap_encoding_error(), because charmap_encoding_error() got it's own copy of the errorHandler pointer instead of a pointer to the pointer in PyUnicode_EncodeCharmap().
* Fix reference leak noted in test_types:Michael W. Hudson2003-08-141-9/+9
| | | | | | Check for a[:] = a _before_ calling PySequence_Fast on a. release23-maint candidate Reference leak doesn't happen with head of release22-maint.
* Add a couple of decrefs to error paths.Michael W. Hudson2003-08-111-2/+4
| | | | | | | Now test_descr only appears to leak two references & I think this are in fact illusory (it's to do with things getting resurrected in __del__ methods & it's easy to be believe confusion occurs when that happens <wink>). Woohoo!
* Fix silly typo in comment.Michael W. Hudson2003-08-111-1/+1
|
* /* XXX From here until type is allocated, "return NULL" leaks bases! */Michael W. Hudson2003-08-081-2/+9
| | | | | | | | | | | | Sure looks like it to me! <wink> When I run the leak2.py script I posted to python-dev, I only see three reference leaks in all of test_descr. When I run test_descr.test_main, I still see 46 leaks. This clearly demands posting a yelp to python-dev :-) This certainly should be applied to release23-maint, and in all likelyhood release22-maint as well.
* Repair refcounting on error return from type_set_bases.Michael W. Hudson2003-08-071-3/+6
| | | | Include a test case that failed for one of my efforts to repair this.
* Remove code that tried to warn about shadowing builtin names after aNeil Schemenauer2003-07-161-66/+1
| | | | module had been compiled. It gives too many spurious warnings.
* Remove stray comments.Jeremy Hylton2003-07-161-1/+0
|
* Remove unnecessary check in tests for slots allowed.Jeremy Hylton2003-07-161-1/+1
| | | | | | | The !PyType_Check(base) check snuck in as part of rev 2.215, but was unrelated to the SF patch that is mentioned in the checkin comment. The test is currently unnecessary because base is set to the return value of best_bases(), which returns a type or NULL.
* Remove proxy_print(), since that caused an inconsistency betweenFred Drake2003-07-141-10/+2
| | | | | "print repr(proxy(a))" and "proxy(a)" at an interactive prompt. Closes SF bug #722763.
* Add whitespace.Jeremy Hylton2003-07-111-3/+3
|
* Support 'mbcs' as a 'built-in' encoding, so the C API can use it withoutMark Hammond2003-07-011-0/+19
| | | | | defering to the encodings package. As described in [ 763111 ] mbcs encoding should skip encodings package
* Fix SF 762891: "del p[key]" on proxy object raises SystemError()Raymond Hettinger2003-06-301-1/+5
|
* SF patch 703666: Several objects don't decref tmp on failure in subtype_newRaymond Hettinger2003-06-284-4/+13
| | | | | | Submitted By: Christopher A. Craig Fillin some missing decrefs.
* Require that __nonzero__() return a bool or exactly an int.Jeremy Hylton2003-06-271-6/+2
|
* Check return type of __nonzero__() method.Jeremy Hylton2003-06-271-1/+13
| | | | | | The language reference says you must return an int or a bool. This fix limits the scope of SF bug 759227 (infinite recursion) to subclasses of int.
* Whitespace normalization.Walter Dörwald2003-06-251-3/+3
|
* Fix whitespace.Walter Dörwald2003-06-181-1/+1
|
* SF bug #753451: classmethod abuse --> SystemErrorRaymond Hettinger2003-06-181-0/+6
| | | | | | Check the argument to classmethod for callability. Backport candidate.
* Fix typo in comment.Walter Dörwald2003-06-171-1/+1
|
* Use _PyEval_SliceIndex to handle list.index() calls withWalter Dörwald2003-06-171-1/+3
| | | | huge start and stop arguments. Add tests.
* Whitespace normalization.Walter Dörwald2003-06-171-6/+6
|
generated by cgit v0.12 at 2024-12-04 18:52:36 (GMT)