summaryrefslogtreecommitdiffstats
path: root/Objects/object.c
Commit message (Collapse)AuthorAgeFilesLines
* Speedup for PyObject_IsTrue(): check for True and False first.Guido van Rossum2002-08-241-0/+4
| | | | | Because all built-in tests return bools now, this is the most common path!
* Speedup for PyObject_RichCompareBool(): PyObject_RichCompare() almostGuido van Rossum2002-08-241-1/+4
| | | | | always returns a bool, so avoid calling PyObject_IsTrue() in that case.
* Another modest speedup in PyObject_GenericGetAttr(): inline the callGuido van Rossum2002-08-191-2/+26
| | | | to _PyType_Lookup().
* Inline call to _PyObject_GetDictPtr() in PyObject_GenericGetAttr().Guido van Rossum2002-08-191-3/+20
| | | | This causes a modest speedup.
* Replace abort with Py_FatalError.Martin v. Löwis2002-08-071-1/+1
|
* Excise DL_IMPORT/EXPORT from object.h, and related files. This patchMark Hammond2002-07-291-2/+2
| | | | | also adds 'extern' to PyAPI_DATA rather than at each declaration, as discussed with Tim and Guido.
* object.h special-build macro minefield: renamed all the new lexicalTim Peters2002-07-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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-071-43/+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.
* SF # 533070 Silence AIX C Compiler WarningsNeal Norwitz2002-06-131-1/+1
| | | | Warning caused by using &func. & is not necessary.
* SF # 561244 Micro optimizationsNeal Norwitz2002-06-131-5/+3
| | | | Cleanup code a bit and return as early as possible.
* 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?
* - A new type object, 'string', is added. This is a common base typeGuido van Rossum2002-05-241-0/+3
| | | | | | | for 'str' and 'unicode', and can be used instead of types.StringTypes, e.g. to test whether something is "a string": isinstance(x, string) is True for Unicode and 8-bit strings. This is an abstract base class and cannot be instantiated directly.
* Jim Fulton reported a segfault in dir(). A heavily proxied objectGuido van Rossum2002-05-131-7/+15
| | | | | | | | returned a proxy for __class__ whose __bases__ was also a proxy. The merge_class_dict() helper for dir() assumed incorrectly that __bases__ would always be a tuple and used the in-line tuple API on the proxy. I will backport this to 2.2 as well.
* PyNumber_CoerceEx: this took a shortcut (not doing anything) when theGuido van Rossum2002-04-261-1/+4
| | | | | | | | | | | | | | | | | | | | | left and right type were of the same type and not classic instances. This shortcut is dangerous for proxy types, because it means that coerce(Proxy(1), Proxy(2.1)) leaves Proxy(1) unchanged rather than turning it into Proxy(1.0). In an ever-so-slight change of semantics, I now only take the shortcut when the left and right types are of the same type and don't have the CHECKTYPES feature. It so happens that classic instances have this flag, so the shortcut is still skipped in this case (i.e. nothing changes for classic instances). Proxies also have this flag set (otherwise implementing numeric operations on proxies would become nightmarish) and this means that the shortcut is also skipped there, as desired. It so happens that int, long and float also have this flag set; that means that e.g. coerce(1, 1) will now invoke int_coerce(). This is fine: int_coerce() can deal with this, and I'm not worried about the performance; int_coerce() is only invoked when the user explicitly calls coerce(), which should be rarer than rare.
* First stab at rationalizing the PyMem_ API. Mixing PyObject_xyz withTim Peters2002-04-121-6/+1
| | | | | | | | | | | | | | | | | | | | | | | | PyMem_{Del, DEL} doesn't work yet (compilation problems). pyport.h: _PyMem_EXTRA is gone. pmem.h: Repaired comments. PyMem_{Malloc, MALLOC} and PyMem_{Realloc, REALLOC} now make the same x-platform guarantees when asking for 0 bytes, and when passing a NULL pointer to the latter. object.c: PyMem_{Malloc, Realloc} just call their macro versions now, since the latter take care of the x-platform 0 and NULL stuff by themselves now. pypcre.c, grow_stack(): So sue me. On two lines, this called PyMem_RESIZE to grow a "const" area. It's not legit to realloc a const area, so the compiler warned given the new expansion of PyMem_RESIZE. It would have gotten the same warning before if it had used PyMem_Resize() instead; the older macro version, but not the function version, silently cast away the constness. IMO that was a wrong thing to do, and the docs say the macro versions of PyMem_xyz are deprecated anyway. If somebody else is resizing const areas with the macro spelling, they'll get a warning when they recompile now too.
* Move PyObject_Malloc and PyObject_Free to obmalloc.c.Neil Schemenauer2002-04-121-21/+2
|
* Add the 'bool' type and its values 'False' and 'True', as described inGuido van Rossum2002-04-031-0/+3
| | | | | | | | | | | | | PEP 285. Everything described in the PEP is here, and there is even some documentation. I had to fix 12 unit tests; all but one of these were printing Boolean outcomes that changed from 0/1 to False/True. (The exception is test_unicode.py, which did a type(x) == type(y) style comparison. I could've fixed that with a single line using issubtype(x, type(y)), but instead chose to be explicit about those places where a bool is expected. Still to do: perhaps more documentation; change standard library modules to return False/True from predicates.
* If the GC is enabled then don't use the ob_type pointer to create a listNeil Schemenauer2002-03-291-1/+12
| | | | of trash objects. Use the gc_prev pointer instead.
* Build obmalloc.c directly instead of #include'ing from object.c.Tim Peters2002-03-231-43/+0
| | | | | | | | Also move all _PyMalloc_XXX entry points into obmalloc.c. The Windows build works fine. The Unix build is changed here (Makefile.pre.in), but not tested. No other platform's build process has been fiddled.
* Add pymalloc object memory management functions. These must beNeil Schemenauer2002-03-221-0/+24
| | | | | available even if pymalloc is disabled since extension modules might use them.
* Drop the PyCore_* memory API.Neil Schemenauer2002-03-181-1/+16
|
* Patch #517521: Consider byte strings before Unicode stringsMartin v. Löwis2002-03-151-52/+60
| | | | in PyObject_Get/SetAttr.
* Whether platform malloc(0) returns NULL has nothing to do with whetherTim Peters2002-03-021-5/+2
| | | | | | | | | | | platform realloc(p, 0) returns NULL, so MALLOC_ZERO_RETURNS_NULL can be correctly undefined yet realloc(p, 0) can return NULL anyway. Prevent realloc(p, 0) doing free(p) and returning NULL via a different hack. Would probably be better to get rid of MALLOC_ZERO_RETURNS_NULL entirely. Bugfix candidate.
* SF patch 514641 (Naofumi Honda) - Negative ob_size of LongObjectsGuido van Rossum2002-03-011-2/+8
| | | | | | | | | | Due to the bizarre definition of _PyLong_Copy(), creating an instance of a subclass of long with a negative value could cause core dumps later on. Unfortunately it looks like the behavior of _PyLong_Copy() is quite intentional, so the fix is more work than feels comfortable. This fix is almost, but not quite, the code that Naofumi Honda added; in addition, I added a test case.
* PyObject_Generic{Get,Set}Attr(): ensure that the attribute name is aGuido van Rossum2001-12-041-20/+72
| | | | | | | string object (or a Unicode that's trivially converted to ASCII). PyObject_GetAttr(): add an 'else' to the Unicode test like PyObject_SetAttr() already has.
* Rehabilitated the fast-path richcmp code, and sped it up. It wasn'tTim Peters2001-11-041-31/+35
| | | | | | | | | | | | | | | helping for types that defined tp_richcmp but not tp_compare, although that's when it's most valuable, and strings moved into that category since the fast path was first introduced. Now it helps for same-type non-Instance objects that define rich or 3-way compares. For all the edits here, the rest just amounts to moving the fast path from do_richcmp into PyObject_RichCompare, saving a layer of function call (measurable on my box!). This loses when NESTING_LIMIT is exceeded, but I don't care about that (fast-paths are for normal cases, not pathologies). Also added a tasteful <wink> label to get out of PyObject_RichCompare, as the if/else nesting in this routine was getting incomprehensible.
* No code change -- just trying to document the return conditions for allTim Peters2001-11-041-17/+43
| | | | the internal comparison routines.
* cleanup indentationJeremy Hylton2001-10-221-1/+1
|
* SF patch #470578: Fixes to synchronize unicode() and str()Guido van Rossum2001-10-191-16/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements what we have discussed on python-dev late in September: str(obj) and unicode(obj) should behave similar, while the old behaviour is retained for unicode(obj, encoding, errors). The patch also adds a new feature with which objects can provide unicode(obj) with input data: the __unicode__ method. Currently no new tp_unicode slot is implemented; this is left as option for the future. Note that PyUnicode_FromEncodedObject() no longer accepts Unicode objects as input. The API name already suggests that Unicode objects do not belong in the list of acceptable objects and the functionality was only needed because PyUnicode_FromEncodedObject() was being used directly by unicode(). The latter was changed in the discussed way: * unicode(obj) calls PyObject_Unicode() * unicode(obj, encoding, errors) calls PyUnicode_FromEncodedObject() One thing left open to discussion is whether to leave the PyUnicode_FromObject() API as a thin API extension on top of PyUnicode_FromEncodedObject() or to turn it into a (macro) alias for PyObject_Unicode() and deprecate it. Doing so would have some surprising consequences though, e.g. u"abc" + 123 would turn out as u"abc123"... [Marc-Andre didn't have time to check this in before the deadline. I hope this is OK, Marc-Andre! You can still make changes and commit them on the trunk after the branch has been made, but then please mail Barry a context diff if you want the change to be merged into the 2.2b1 release branch. GvR]
* SF bug [#468061] __str__ ignored in str subclass.Tim Peters2001-10-161-6/+0
| | | | | | | | | | | | | | | | | object.c, PyObject_Str: Don't try to optimize anything except exact string objects here; in particular, let str subclasses go thru tp_str, same as non-str objects. This allows overrides of tp_str to take effect. stringobject.c: + string_print (str's tp_print): If the argument isn't an exact string object, get one from PyObject_Str. + string_str (str's tp_str): Make a genuine-string copy of the object if it's of a proper str subclass type. str() applied to a str subclass that doesn't override __str__ ends up here. test_descr.py: New str_of_str_subclass() test.
* Guido suggests, and I agree, to insist that SIZEOF_VOID_P be a power of 2.Tim Peters2001-10-071-5/+3
| | | | | | This simplifies the rounding in _PyObject_VAR_SIZE, allows to restore the pre-rounding calling sequence, and allows some nice little simplifications in its callers. I'm still making it return a size_t, though.
* _PyObject_VAR_SIZE: always round up to a multiple-of-pointer-size value.Tim Peters2001-10-061-18/+11
| | | | | | | | | | | | | | | | | As Guido suggested, this makes the new subclassing code substantially simpler. But the mechanics of doing it w/ C macro semantics are a mess, and _PyObject_VAR_SIZE has a new calling sequence now. Question: The PyObject_NEW_VAR macro appears to be part of the public API. Regardless of what it expands to, the notion that it has to round up the memory it allocates is new, and extensions containing the old PyObject_NEW_VAR macro expansion (which was embedded in the PyObject_NEW_VAR expansion) won't do this rounding. But the rounding isn't actually *needed* except for new-style instances with dict pointers after a variable-length blob of embedded data. So my guess is that we do not need to bump the API version for this (as the rounding isn't needed for anything an extension can do unless it's recompiled anyway). What's your guess?
* _PyObject_GetDictPtr():Tim Peters2001-10-061-8/+12
| | | | | | + Use the _PyObject_VAR_SIZE macro to compute object size. + Break the computation into lines convenient for debugger inspection. + Speed the round-up-to-pointer-size computation.
* PyObject_ClearWeakRefs() is now a real function instead of a function pointer;Fred Drake2001-10-051-15/+0
| | | | the implementation is in Objects/weakrefobject.c.
* Merge branch changes (coercion, rich comparisons) into trunk.Guido van Rossum2001-09-271-0/+8
|
* _PyObject_GetDictPtr(): when the offset is negative, always align --Guido van Rossum2001-09-201-11/+6
| | | | we can't trust that tp_basicsize is aligned. Fixes SF bug #462848.
* Hopefully fix 3-way comparisons. This unfortunately adds yet anotherGuido van Rossum2001-09-181-1/+15
| | | | | | | | hack, and it's even more disgusting than a PyInstance_Check() call. If the tp_compare slot is the slot used for overrides in Python, it's always called. Add some tests that show what should work too.
* PyObject_Dir(): Merge in __members__ and __methods__ too (if they exist,Tim Peters2001-09-171-0/+45
| | | | | | | | | | | | | | | and are lists, and then just the string elements (if any)). There are good and bad reasons for this. The good reason is to support dir() "like before" on objects of extension types that haven't migrated to the class introspection API yet. The bad reason is that Python's own method objects are such a type, and this is the quickest way to get their im_self etc attrs to "show up" via dir(). It looks much messier to move them to the new scheme, as their current getattr implementation presents a view of their attrs that's a untion of their own attrs plus their im_func's attrs. In particular, methodobject.__dict__ actually returns methodobject.im_func.__dict__, and if that's important to preserve it doesn't seem to fit the class introspection model at all.
* merge_class_dict(): Clear the error if __bases__ doesn't exist.Tim Peters2001-09-161-1/+3
|
* _PyObject_Dump(): print the type of the object. This is by far theGuido van Rossum2001-09-141-2/+8
| | | | most frequently interesting information IMO. Also tidy up the output.
* More on SF bug [#460020] bug or feature: unicode() and subclasses.Tim Peters2001-09-111-1/+7
| | | | | Repaired str(i) to return a genuine string when i is an instance of a str subclass. New PyString_CheckExact() macro.
* PyObject_Dir():Guido van Rossum2001-09-101-2/+6
| | | | | | - use PyModule_Check() instead of PyObject_TypeCheck(), now we can. - don't assert that the __dict__ gotten out of a module is always a dictionary; check its type, and raise an exception if it's not.
* At Guido's suggestion, here's a new C API function, PyObject_Dir(), likeTim Peters2001-09-041-0/+145
| | | | __builtin__.dir(). Moved the guts from bltinmodule.c to object.c.
* Add warning mode for classic division, almost exactly as specified inGuido van Rossum2001-08-311-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PEP 238. Changes: - add a new flag variable Py_DivisionWarningFlag, declared in pydebug.h, defined in object.c, set in main.c, and used in {int,long,float,complex}object.c. When this flag is set, the classic division operator issues a DeprecationWarning message. - add a new API PyRun_SimpleStringFlags() to match PyRun_SimpleString(). The main() function calls this so that commands run with -c can also benefit from -Dnew. - While I was at it, I changed the usage message in main() somewhat: alphabetized the options, split it in *four* parts to fit in under 512 bytes (not that I still believe this is necessary -- doc strings elsewhere are much longer), and perhaps most visibly, don't display the full list of options on each command line error. Instead, the full list is only displayed when -h is used, and otherwise a brief reminder of -h is displayed. When -h is used, write to stdout so that you can do `python -h | more'. Notes: - I don't want to use the -W option to control whether the classic division warning is issued or not, because the machinery to decide whether to display the warning or not is very expensive (it involves calling into the warnings.py module). You can use -Werror to turn the warnings into exceptions though. - The -Dnew option doesn't select future division for all of the program -- only for the __main__ module. I don't know if I'll ever change this -- it would require changes to the .pyc file magic number to do it right, and a more global notion of compiler flags. - You can usefully combine -Dwarn and -Dnew: this gives the __main__ module new division, and warns about classic division everywhere else.
generated by cgit v0.12 at 2024-10-21 05:15:33 (GMT)