summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* SF bug 578752: COUNT_ALLOCS vs heap typesTim Peters2002-07-081-0/+9
| | | | | | | Repair segfaults and infinite loops in COUNT_ALLOCS builds in the presence of new-style (heap-allocated) classes/types. Bugfix candidate. I'll backport this to 2.2. It's irrelevant in 2.1.
* Rearranged and added comments to object.h, to clarify many thingsTim Peters2002-07-071-6/+2
| | | | | | | | | | | that have taken me "too long" to reverse-engineer over the years. Vastly reduced the nesting level and redundancy of #ifdef-ery. Took a light stab at repairing comments that are no longer true. sys_gettotalrefcount(): Changed to enable under Py_REF_DEBUG. It was enabled under Py_TRACE_REFS, which was much heavier than necessary. sys.gettotalrefcount() is now available in a Py_REF_DEBUG-only build.
* Removed 3 unlikely #includes that were only needed for the non-gc flavorTim Peters2002-07-071-5/+0
| | | | of the trashcan code.
* Trashcan cleanup: Now that cyclic gc is always there, the trashcanTim Peters2002-07-071-50/+40
| | | | | | | | | | | | | | | | | | | mechanism is no longer evil: it no longer plays dangerous games with the type pointer or refcounts, and objects in extension modules can play along too without needing to edit the core first. Rewrote all the comments to explain this, and (I hope) give clear guidance to extension authors who do want to play along. Documented all the functions. Added more asserts (it may no longer be evil, but it's still dangerous <0.9 wink>). Rearranged the generated code to make it clearer, and to tolerate either the presence or absence of a semicolon after the macros. Rewrote _PyTrash_destroy_chain() to call tp_dealloc directly; it was doing a Py_DECREF again, and that has all sorts of obscure distorting effects in non-release builds (Py_DECREF was already called on the object!). Removed Christian's little "embedded change log" comments -- that's what checkin messages are for, and since it was impossible to correlate the comments with the code that changed, I found them merely distracting.
* Removed WITH_CYCLE_GC #ifdef-ery. Holes:Tim Peters2002-07-072-46/+0
| | | | | | + I'm not sure what to do about configure.in. Left it alone. + Ditto pyexpat.c. Fred or Martin will know what to do.
* Patch #569753: Remove support for WIN16.Martin v. Löwis2002-06-302-6/+6
| | | | Rename all occurrences of MS_WIN32 to MS_WINDOWS.
* Fix SF bug 546434 -- buffer slice type inconsistent.Raymond Hettinger2002-06-251-13/+0
|
* Fix SF bug 572567: Memory leak in object comparison.Raymond Hettinger2002-06-241-0/+1
|
* Fix for SF bug 571885Jeremy Hylton2002-06-201-2/+2
| | | | | When resizing a tuple, zero out the memory starting at the end of the old tuple not at the beginning of the old tuple.
* SF 569257 -- Name mangle double underscored variable names in __slots__.Raymond Hettinger2002-06-201-1/+21
|
* Fix the bug described inMichael W. Hudson2002-06-191-5/+9
| | | | | | | | | http://mail.python.org/pipermail/python-dev/2002-June/025461.html with test cases. Also includes extended slice support for arrays, which I thought I'd already checked in but obviously not.
* Patch from SF bug 570483 (Tim Northover).Guido van Rossum2002-06-181-0/+5
| | | | | | In a fresh interpreter, type.mro(tuple) would segfault, because PyType_Ready() isn't called for tuple yet. To fix, call PyType_Ready(type) if type->tp_dict is NULL.
* About the new but unreferenced new_class, Guido sez:Michael W. Hudson2002-06-181-15/+0
| | | | | | | > Looks like an experiment by Oren Tirosh that didn't get nuked. I > think you can safely lose it. It's gone.
* SF patch 568629 by Oren Tirosh: types made callable.Guido van Rossum2002-06-145-9/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]
* Inexplicably, recurse_down_subclasses() was comparing the objectGuido van Rossum2002-06-141-1/+2
| | | | | | gotten from a weak reference to NULL instead of to None. This caused the following assert() to fail (but only in 2.2 in the debug build -- I have to find a better test case). Will backport.
* Missed one use of new PyDoc_STRVAR macroNeal Norwitz2002-06-141-2/+2
|
* SF bug # 493951 string.{starts,ends}with vs slicesNeal Norwitz2002-06-141-45/+36
| | | | Handle negative indices similar to slices.
* SF # 533070 Silence AIX C Compiler WarningsNeal Norwitz2002-06-131-1/+1
| | | | Warning caused by using &func. & is not necessary.
* Major cleanup operation: whenever there's a call that looks for anGuido van Rossum2002-06-131-10/+59
| | | | | | | | | | | | | optional attribute, only clear the exception when the internal getattr operation raised AttributeError. Many places in this file already had that policy; but just as many didn't, and there didn't seem to be any rhyme or reason to it. Be consistently cautious. Question: should I backport this? On the one hand it's a bugfix. On the other hand it's a change in behavior. Certain forms of buggy or just weird code would work in the past but raise an exception under the new rules; e.g. if you define a __getattr__ method that raises a non-AttributeError exception.
* Fix for SF bug 532646. This is a little simpler than what NealGuido van Rossum2002-06-131-1/+17
| | | | | suggested there, based upon a better analysis (__getattr__ is a red herring). Will backport to 2.2.
* SF # 561244 Micro optimizationsNeal Norwitz2002-06-131-5/+3
| | | | Cleanup code a bit and return as early as possible.
* Fix typo in exception messageNeal Norwitz2002-06-131-1/+1
|
* SF #561244 Micro optimizationsNeal Norwitz2002-06-132-10/+6
| | | | Convert loops to memset()s.
* Patch #568124: Add doc string macros.Martin v. Löwis2002-06-1318-254/+260
|
* Hopefully this addresses the remaining issues of SF bugs 459235 andGuido van Rossum2002-06-131-24/+39
| | | | | | 473985. Through a subtle rearrangement of some members in the etype struct (!), mapping methods are now preferred over sequence methods, which is necessary to support str.__getitem__("hello", slice(4)) etc.
* Rearrange the #ifndef WITHOUT_COMPLEX so it can be picked up fromGuido van Rossum2002-06-131-2/+2
| | | | pyconfig.h.
* Fix for problem reported by Neal Norwitz. Tighten up calculation ofMichael W. Hudson2002-06-111-3/+5
| | | | slicelength. Include his test case.
* Fold remaining long lines.Guido van Rossum2002-06-111-2/+6
|
* This is my nearly two year old patchMichael W. Hudson2002-06-115-6/+414
| | | | | | | | | [ 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.
* Undo the last chunk of the previous patch, putting back a usefulGuido van Rossum2002-06-101-1/+3
| | | | | assert into PyType_Ready(): now that we're not clearing tp_dict, we can assert that it's non-NULL again.
* In the recent python-dev thread "Bizarre new test failure", weGuido van Rossum2002-06-101-32/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | discovered that subtype_traverse must traverse the type if it is a heap type, because otherwise some cycles involving a type and its instance would not be collected. Simplest example: while 1: class C(object): pass C.ref = C() This program grows without bounds before this fix. (It grows ever slower since it spends ever more time in the collector.) Simply adding the right visit() call to subtype_traverse() revealed other problems. With MvL's help we re-learned that type_clear() doesn't have to clear *all* references, only the ones that may not be cleared by other means. Careful analysis (see comments in the code) revealed that only tp_mro needs to be cleared. (The previous checkin to this file adds a test for tp_mro==NULL to _PyType_Lookup() that's essential to prevent crashes due to tp_mro being NULL when subtype_dealloc() tries to look for a __del__ method.) The same kind of analysis also revealed that subtype_clear() doesn't need to clear the instance dict. With this fix, a useful property of the collector is once again guaranteed: a single gc.collect() call will clear out all garbage. (It didn't always before, which put us on the track of this bug.) Will backport to 2.2.
* Three's a charm: yet another fix for SF bug 551412. Thinking againGuido van Rossum2002-06-101-19/+17
| | | | | | | | | | | about the test case, slot_nb_power gets called on behalf of its second argument, but with a non-None modulus it wouldn't check this, and believes it is called on behalf of its first argument. Fix this properly, and get rid of the code in _PyType_Lookup() that tries to call _PyType_Ready(). But do leave a check for a NULL tp_mro there, because this can still legitimately occur. I'll fix this in 2.2.x too.
* Close SF bug 563740. complex() now finds __complex__() in new style classes.Raymond Hettinger2002-06-062-28/+25
| | | | | Made conversion failure error messages consistent between types. Added related unittests.
* 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
|
* Better isinstance error message.Thomas Heller2002-06-051-1/+2
| | | | | | Closes SF patch # 560250. Bugfix candidate IMO.
* Address SF bug 519621: slots weren't traversed by GC.Guido van Rossum2002-06-041-49/+137
| | | | | | | | | | | | | | While I was at it, I added a tp_clear handler and changed the tp_dealloc handler to use the clear_slots helper for the tp_clear handler. Also tightened the rules for slot names: they must now be proper identifiers (ignoring the dirty little fact that <ctype.h> is locale sensitive). Also set mp->flags = READONLY for the __weakref__ pseudo-slot. Most of this is a 2.2 bugfix candidate; I'll apply it there myself.
* Inverted test for small speedupRaymond Hettinger2002-06-041-5/+4
|
* Add a docstring to the module type.Guido van Rossum2002-06-041-1/+7
|
* Surprising fix for SF bug 563060: module can be used as base class.Guido van Rossum2002-06-041-3/+16
| | | | | | | | | | | | | | Change the module constructor (module_init) to have the signature __init__(name:str, doc=None); this prevents the call from type_new() to succeed. While we're at it, prevent repeated calling of module_init for the same module from leaking the dict, changing the semantics so that __dict__ is only initialized if NULL. Also adding a unittest, test_module.py. This is an incompatibility with 2.2, if anybody was instantiating the module class before, their argument list was probably empty; so this can't be backported to 2.2.x.
* Address the residual issue with the fix for SF 551412 inGuido van Rossum2002-06-031-1/+11
| | | | | | | _PyType_Lookup(). Decided to clear the error condition in the unfortunate but unlikely case that PyType_Ready() fails. Will fix in 2.2.x too.
* A bogus assert in the new listiter code prevented starting Python in aTim Peters2002-06-011-10/+12
| | | | | debug build. Repaired that, and rewrote other parts to reduce long-winded casting.
* SF 560736. Optimize list iteration by filling the tp_iter slot.Raymond Hettinger2002-05-312-18/+125
|
* Fix typoNeal Norwitz2002-05-311-1/+1
|
* Implement the intention of SF patch 472523 (but coded differently).Guido van Rossum2002-05-311-15/+67
| | | | | | | | | | | | | | | | | | In the past, an object's tp_compare could return any value. In 2.2 the docs were tightened to require it to return -1, 0 or 1; and -1 for an error. We now issue a warning if the value is not in this range. When an exception is raised, we allow -1 or -2 as return value, since -2 will the recommended return value for errors in the future. (Eventually tp_compare will also be allowed to return +2, to indicate NotImplemented; but that can only be implemented once we know all extensions return a value in [-2...1]. Or perhaps it will require the type to set a flag bit.) I haven't decided yet whether to backport this to 2.2.x. The patch applies fine. But is it fair to start warning in 2.2.2 about code that worked flawlessly in 2.2.1?
* Change name from string to basestringNeal Norwitz2002-05-311-3/+3
|
* Fix a possible segfault. Found be Neal Norvitz.Marc-André Lemburg2002-05-291-1/+1
|
* Fix for bug [ 561796 ] string.find causes lazy errorMarc-André Lemburg2002-05-291-2/+2
|
* Fix for SF bug 551412. When _PyType_Lookup() is called on a typeGuido van Rossum2002-05-241-0/+6
| | | | | | whose tp_mro hasn't been initialized, it would dump core. Fix this by checking for NULL and calling PyType_Ready(). Will fix this in 2.2.1 too.
generated by cgit v0.12 at 2025-01-10 01:32:29 (GMT)