summaryrefslogtreecommitdiffstats
path: root/Objects/object.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* PyObject_Repr(): add missing ">" back at end of format string: "<%sGuido van Rossum2001-08-301-1/+1
| | | | object at %p>".
* Remove GC related code. It lives in gcmodule now.Neil Schemenauer2001-08-291-26/+1
|
* repr's converted to using PyString_FromFormat() instead of sprintf'ingBarry Warsaw2001-08-241-6/+4
| | | | | | into a hardcoded char* buffer. Closes patch #454743.
* Patch #445762: Support --disable-unicodeMartin v. Löwis2001-08-171-1/+15
| | | | | | | | - Do not compile unicodeobject, unicodectype, and unicodedata if Unicode is disabled - check for Py_USING_UNICODE in all places that use Unicode functions - disables unicode literals, and the builtin functions - add the types.StringTypes list - remove Unicode literals from most tests.
* Add a function _Py_ReadyTypes() which initializes various and sundryGuido van Rossum2001-08-161-4/+21
| | | | | | | | | types -- currently Type, List, None and NotImplemented. To be called from Py_Initialize() instead of accumulating calls there. Also rename type(None) to NoneType and type(NotImplemented) to NotImplementedType -- naming the type identical to the object was confusing.
* Update to MvL's patch #424475 to avoid returning 2 when tp_compareGuido van Rossum2001-08-161-2/+5
| | | | | | returns that. (This fix is also by MvL; checkin it in because I want to make more changes here. I'm still not 100% satisfied -- see comments attached to the patch.)
* - Rename PyType_InitDict() to PyType_Ready().Guido van Rossum2001-08-071-2/+2
| | | | | | - Add an explicit call to PyType_Ready(&PyList_Type) to pythonrun.c (just for the heck of it, really -- we should either explicitly ready all types, or none).
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-83/+210
|
* Add _PyUnicode_AsDefaultEncodedString to unicodeobject.h.Jeremy Hylton2001-07-301-5/+0
| | | | | | | And remove all the extern decls in the middle of .c files. Apparently, it was excluded from the header file because it is intended for internal use by the interpreter. It's still intended for internal use and documented as such in the header file.
* _Py_GetObjects(): GCC suggests to add () around && within || for someGuido van Rossum2001-07-141-1/+1
| | | | code only compiled in debug mode, and I dutifully comply.
* Patch #424475: Speed-up tp_compare usage, by special-casing the commonMartin v. Löwis2001-06-091-20/+49
| | | | | | case of objects with equal types which support tp_compare. Give type objects a tp_compare function. Also add c<0 tests before a few PyErr_Occurred tests.
* Cosmetic: code under "else" clause was missing indent.Tim Peters2001-05-111-1/+1
|
* SF bug #422108 - Error in rich comparisons.Tim Peters2001-05-071-1/+7
| | | | | | 2.1.1 bugfix candidate too. Fix a bad (albeit unlikely) return value in try_rich_to_3way_compare(). Also document do_cmp()'s return values.
* Make 'x in y' and 'x not in y' (PySequence_Contains) play nice w/ iterators.Tim Peters2001-05-051-0/+1
| | | | | | | | | | | | | NEEDS DOC CHANGES A few more AttributeErrors turned into TypeErrors, but in test_contains this time. The full story for instance objects is pretty much unexplainable, because instance_contains() tries its own flavor of iteration-based containment testing first, and PySequence_Contains doesn't get a chance at it unless instance_contains() blows up. A consequence is that some_complex_number in some_instance dies with a TypeError unless some_instance.__class__ defines __iter__ but does not define __getitem__.
* The weakref support in PyObject_InitVar() as well; this should have come outFred Drake2001-05-031-4/+0
| | | | at the same time as it did from PyObject_Init() .
* Remove unnecessary intialization for the case of weakly-referencable objects;Fred Drake2001-05-031-4/+0
| | | | | | | the code necessary to accomplish this is simpler and faster if confined to the object implementations, so we only do this there. This causes no behaviorial changes beyond a (very slight) speedup.
* Printing objects to a real file still wasn't done right: if theGuido van Rossum2001-05-011-32/+14
| | | | | | | | | | | | | | | | | | | object's type didn't define tp_print, there were still cases where the full "print uses str() which falls back to repr()" semantics weren't honored. This resulted in >>> print None <None object at 0x80bd674> >>> print type(u'') <type object at 0x80c0a80> Fixed this by always using the appropriate PyObject_Repr() or PyObject_Str() call, rather than trying to emulate what they would do. Also simplified PyObject_Str() to always fall back on PyObject_Repr() when tp_str is not defined (rather than making an extra check for instances with a __str__ method). And got rid of the special case for strings.
* (Adding this to the trunk as well.)Guido van Rossum2001-04-271-1/+4
| | | | | | | | Fix a very old flaw in PyObject_Print(). Amazing! When an object type defines tp_str but not tp_repr, 'print x' to a real file object would not call the tp_str slot but rather print a default style representation: <foo object at 0x....>. This even though 'print x' to a file-like-object would correctly call the tp_str slot.
* Fixed ref count bug. Patch #411191. Found by Walter Dörwald.Marc-André Lemburg2001-03-251-1/+3
|
* Add Vladimir Marangozov's object allocator. It is disabled by default. ThisNeil Schemenauer2001-02-271-0/+4
| | | | closes SF patch #401229.
* The return value from PyObject_ClearWeakRefs() is no longer meaningful,Fred Drake2001-02-261-3/+3
| | | | so make it void.
* _PyObject_Dump(): If argument is NULL, print "NULL" instead ofBarry Warsaw2001-02-221-3/+7
| | | | crashing.