summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* object.h special-build macro minefield: renamed all the new lexicalTim Peters2002-07-115-97/+72
| | | | | | | | | | | | | | | | | | | | | | | | | helper macros to something saner, and used them appropriately in other files too, to reduce #ifdef blocks. classobject.c, instance_dealloc(): One of my worst Python Memories is trying to fix this routine a few years ago when COUNT_ALLOCS was defined but Py_TRACE_REFS wasn't. The special-build code here is way too complicated. Now it's much simpler. Difference: in a Py_TRACE_REFS build, the instance is no longer in the doubly-linked list of live objects while its __del__ method is executing, and that may be visible via sys.getobjects() called from a __del__ method. Tough -- the object is presumed dead while its __del__ is executing anyway, and not calling _Py_NewReference() at the start allows enormous code simplification. typeobject.c, call_finalizer(): The special-build instance_dealloc() pain apparently spread to here too via cut-'n-paste, and this is much simpler now too. In addition, I didn't understand why this routine was calling _PyObject_GC_TRACK() after a resurrection, since there's no plausible way _PyObject_GC_UNTRACK() could have been called on the object by this point. I suspect it was left over from pasting the instance_delloc() code. Instead asserted that the object is still tracked. Caution: I suspect we don't have a test that actually exercises the subtype_dealloc() __del__-resurrected-me code.
* Documented PYMALLOC_DEBUG. This completes primary coverage of all theTim Peters2002-07-101-1/+1
| | | | | "special builds" I ever use. If you use others, document them here, or don't be surprised if I rip out the code for them <0.5 wink>.
* The Py_REF_DEBUG/COUNT_ALLOCS/Py_TRACE_REFS macro minefield: addedTim Peters2002-07-091-0/+15
| | | | | | | | | | | | | | | | | | | | | more trivial lexical helper macros so that uses of these guys expand to nothing at all when they're not enabled. This should help sub- standard compilers that can't do a good job of optimizing away the previous "(void)0" expressions. Py_DECREF: There's only one definition of this now. Yay! That was that last one in the family defined multiple times in an #ifdef maze. Py_FatalError(): Changed the char* signature to const char*. _Py_NegativeRefcount(): New helper function for the Py_REF_DEBUG expansion of Py_DECREF. Calling an external function cuts down on the volume of generated code. The previous inline expansion of abort() didn't work as intended on Windows (the program often kept going, and the error msg scrolled off the screen unseen). _Py_NegativeRefcount calls Py_FatalError instead, which captures our best knowledge of how to abort effectively across platforms.
* 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
|
generated by cgit v0.12 at 2025-02-20 05:16:03 (GMT)