summaryrefslogtreecommitdiffstats
path: root/Objects
Commit message (Collapse)AuthorAgeFilesLines
* Hopefully fix 3-way comparisons. This unfortunately adds yet anotherGuido van Rossum2001-09-182-6/+21
| | | | | | | | 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.
* Properly repr classes without module names.Martin v. Löwis2001-09-181-1/+1
|
* wrap_cmpfunc(): added a safety check for the __cmp__ wrapper. We canGuido van Rossum2001-09-181-0/+9
| | | | | | only safely call a type's tp_compare slot if the second argument is also an instance of the same type. I hate to think what e.g. int_compare() would do with a second argument that's a float!
* Redo the PyMethod attributes using a dir()-friendly approach, creatingGuido van Rossum2001-09-181-37/+69
| | | | | | | | | | | | | | | | | descriptors for each attribute. The getattr() implementation is similar to PyObject_GenericGetAttr(), but delegates to im_self instead of looking in __dict__; I couldn't do this as a wrapper around PyObject_GenericGetAttr(). XXX A problem here is that this is a case of *delegation*. dir() doesn't see exactly the same attributes that are actually defined; e.g. if the delegate is a Python function object, it supports attributes like func_code etc., but these are not visible to dir(); on the other hand, dynamic function attributes (stored in the function's __dict__) *are* visible to dir(). Maybe we need a mechanism to tell dir() about the delegation mechanism? I vaguely recall seeing a request in the newsgroup for a more formal definition of attribute delegation too. Sigh, time for a new PEP.
* type_new(): Didn't compile anymore, due to change in struct memberlistTim Peters2001-09-181-1/+1
| | | | definition. Guido, what else did you forget to check in <wink>?
* Rewrite function attributes to use the generic routines properly.Guido van Rossum2001-09-171-72/+118
| | | | | This uses the new "restricted" feature of structmember, and getset descriptors for some of the type checks.
* 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
|
* A fix for SF bug #461546 (bug in long_mul).Guido van Rossum2001-09-152-14/+20
| | | | | | | | | Both int and long multiplication are changed to be more careful in their assumptions about when one of the arguments is a sequence: the assumption that at least one of the arguments must be an int (or long, respectively) is still held, but the assumption that these don't smell like sequences is no longer true: a subtype of int or long may well have a sequence-repeat thingie!
* tp_new_wrapper(): A subtle change in the check for safe use.Guido van Rossum2001-09-141-1/+1
| | | | Allow staticbase != type, as long as their tp_new slots are the same.
* Add call_maybe(): a variant of call_method() that returnsGuido van Rossum2001-09-141-10/+67
| | | | | | NotImplemented when the lookup fails, and use this for binary operators. Also lookup_maybe() which doesn't raise an exception when the lookup fails (still returning NULL).
* call_method():Guido van Rossum2001-09-141-36/+27
| | | | | | | | | | | | | | | | | | | | | | | - Don't turn a non-tuple argument into a one-tuple. Rather, the caller must pass a format that causes Py_VaBuildValue() to return a tuple. - Speed things up by calling PyObject_Call (which is fairly low-level and straightforward) rather than PyObject_CallObject (which calls PyEval_CallObjectWithKeywords which calls PyObject_Call, and nothing is really done in the mean time except some tests for NULL args and valid types, which are already guaranteed). - Cosmetics. Other places: - Make sure that the format argument to call_method() is surrounded by parentheses, so it will cause a tuple to be created. - Replace a few calls to PyEval_CallObject() with a surefire tuple for args to calls to PyObject_Call(). (A few calls to PyEval_CallObject() remain that have NULL for args.)
* PyObject_CallObject(): this may as well call PyEval_CallObject()Guido van Rossum2001-09-141-16/+1
| | | | | | | | | | | | | | | directly, as the only thing done here (replace NULL args with an empty tuple) is also done there. XXX Maybe we should take one step further and equate the two at the macro level? That's harder though because PyEval_Call* is declared in a header that's not included standard. But it is silly that PyObject_CallObject calls PyEval_CallObject which calls back to PyObject_Call. Maybe PyEval_CallObject should be moved into this file instead? All I know is that there are too many call APIs! The differences between PyObject_Call and PyEval_CallObjectWithKeywords is that the latter allows args to be NULL, and does explicit type checks for args and kwds.
* _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.
* The end of [#460467] file objects should be subclassable.Tim Peters2001-09-141-30/+63
| | | | | | | | A surprising number of changes to split tp_new into tp_new and tp_init. Turned out the older PyFile_FromFile() didn't initialize the memory it allocated in all (error) cases, which caused new sanity asserts elsewhere to fail left & right (and could have, e.g., caused file_dealloc to try decrefing random addresses).
* Changed the dict implementation to take "string shortcuts" only whenTim Peters2001-09-141-13/+16
| | | | | | | | | | | | | | | | keys are true strings -- no subclasses need apply. This may be debatable. The problem is that a str subclass may very well want to override __eq__ and/or __hash__ (see the new example of case-insensitive strings in test_descr), but go-fast shortcuts for strings are ubiquitous in our dicts (and subclass overrides aren't even looked for then). Another go-fast reason for the change is that PyCheck_StringExact() is a quicker test than PyCheck_String(), and we make such a test on virtually every access to every dict. OTOH, a str subclass may also be perfectly happy using the base str eq and hash, and this change slows them a lot. But those cases are still hypothetical, while Python's own reliance on true-string dicts is not.
* Get rid of builtin_open() entirely (the C code and docstring, not theTim Peters2001-09-131-2/+2
| | | | | builtin function); Guido pointed out that it could be just another name in the __builtin__ dict for the file constructor now.
* Now that file objects are subclassable, you can get at the file constructorTim Peters2001-09-131-0/+8
| | | | | | just by doing type(f) where f is any file object. This left a hole in restricted execution mode that rexec.py can't plug by itself (although it can plug part of it; the rest is plugged in fileobject.c now).
* type_call(): Change in policy. The keyword args (if any) are now passedTim Peters2001-09-131-1/+1
| | | | | | on to the tp_new slot (if non-NULL), as well as to the tp_init slot (if any). A sane type implementing both tp_new and tp_init should probably pay attention to the arguments in only one of them.
* based upon a suggestion in c.l.py, this slight expansion of theSkip Montanaro2001-09-131-1/+1
| | | | OverflowError message seems reasonable.
* SF bug [#460467] file objects should be subclassable.Tim Peters2001-09-131-23/+100
| | | | Preliminary support. What's here works, but needs fine-tuning.
* Again perhaps the end of [#460020] bug or feature: unicode() and subclasses.Tim Peters2001-09-122-12/+20
| | | | | Inhibited complex unary plus optimization when applied to a complex subtype. Added PyComplex_CheckExact macro. Some comments and minor code fiddling.
* If interning an instance of a string subclass, intern a real string objectTim Peters2001-09-121-4/+20
| | | | | | with the same value instead. This ensures that a string (or string subclass) object's ob_sinterned pointer is always a str (or NULL), and that the dict of interned strings only has strs as keys.
* str_subtype_new, unicode_subtype_new:Tim Peters2001-09-122-15/+26
| | | | | | | | + These were leaving the hash fields at 0, which all string and unicode routines believe is a legitimate hash code. As a result, hash() applied to str and unicode subclass instances always returned 0, which in turn confused dict operations, etc. + Changed local names "new"; no point to antagonizing C++ compilers.
* More on bug 460020: disable many optimizations of unicode subclasses.Tim Peters2001-09-121-10/+11
|
* More bug 460020: lots of string optimizations inhibited for stringTim Peters2001-09-121-79/+46
| | | | | | | | | subclasses, all "the usual" ones (slicing etc), plus replace, translate, ljust, rjust, center and strip. I don't know how to be sure they've all been caught. Question: Should we complain if someone tries to intern an instance of a string subclass? I hate to slow any code on those paths.
* long_invert(): tiny speed and space optimization.Tim Peters2001-09-111-2/+1
|
* More bug 460020. Disable a number of long optimizations for long subclasses.Tim Peters2001-09-111-18/+15
|
* More bug 460020: when F is a subclass of float, disable the unary plusTim Peters2001-09-111-2/+6
| | | | optimization (+F(whatever)).
* More bug 460020. When I is a subclass of int, disable the +I(whatever),Tim Peters2001-09-111-10/+10
| | | | | I(0) << whatever, I(0) >> whatever, I(whatever) << 0 and I(whatever) >> 0 optimizations.
* The endless 460020 bug.Tim Peters2001-09-111-6/+9
| | | | Disable t[:], t*0, t*1 optimizations when t is of a tuple subclass type.
* Replace a few places where X->ob_type was compared to &PyXXX_Type withGuido van Rossum2001-09-112-7/+7
| | | | calls to PyXXX_CheckExact(X).
* Possibly the end of SF [#460020] bug or feature: unicode() and subclasses.Tim Peters2001-09-111-4/+12
| | | | | Changed unicode(i) to return a true Unicode object when i is an instance of a unicode subclass. Added PyUnicode_CheckExact macro.
* PyUnicode_FromEncodedObject(): Repair memory leak in an error case.Tim Peters2001-09-111-2/+2
|
* More on SF bug [#460020] bug or feature: unicode() and subclasses.Tim Peters2001-09-112-2/+8
| | | | | Repaired str(i) to return a genuine string when i is an instance of a str subclass. New PyString_CheckExact() macro.
* Fix tortured comment -- I must be on drugs today.Tim Peters2001-09-101-2/+2
|
* More on SF bug [#460020] bug or feature: unicode() and subclasses.Tim Peters2001-09-101-1/+5
| | | | | | | | tuple(i) repaired to return a true tuple when i is an instance of a tuple subclass. Added PyTuple_CheckExact macro. PySequence_Tuple(): if a tuple-like object isn't exactly a tuple, it's not safe to return the object as-is -- make a new tuple of it instead.
* More for SF bug [#460020] bug or feature: unicode() and subclassesTim Peters2001-09-101-1/+5
| | | | | Repair float constructor to return a true float when passed a subclass instance. New PyFloat_CheckExact macro.
* SF bug #460020: bug or feature: unicode() and subclasses.Tim Peters2001-09-102-3/+29
| | | | | | | | | | | Given an immutable type M, and an instance I of a subclass of M, the constructor call M(I) was just returning I as-is; but it should return a new instance of M. This fixes it for M in {int, long}. Strings, floats and tuples remain to be done. Added new macros PyInt_CheckExact and PyLong_CheckExact, to more easily distinguish between "is" and "is a" (i.e., only an int passes PyInt_CheckExact, while any sublass of int passes PyInt_Check). Added private API function _PyLong_Copy.
* _portable_fseek():Guido van Rossum2001-09-101-0/+6
| | | | | | | | | | | | | | | | | | | | | Subtlety on Windows: if we change test_largefile.py to use a file > 4GB, it still fails. A debug session suggests this is because fseek(fp, 0, 2) refuses to seek to the end of the file when the file is > 4GB, because it uses the SetFilePointer() in 32-bit mode. But it only fails when we seek relative to the end of the file, because in the other seek modes only calls to fgetpos() and fsetpos() are made, which use Get/SetFilePointer() in 64-bit mode. Solution: #ifdef MS_WInDOWS, replace the call to fseek(fp, ...) with a call to _lseeki64(fileno(fp), ...). Make sure to call fflush(fp) first. (XXX Could also replace the entire branch with a call to _lseeki64(). Would that be more efficient? Certainly less generated code.) (XXX This needs more testing. I can't actually test that it works for files >4GB on my Win98 machine, because the filesystem here won't let me create files >=4GB at all. Tim should test this on his Win2K machine.)
* 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.
* Generalize operator.indexOf (PySequence_Index) to work with anyTim Peters2001-09-083-74/+66
| | | | | | | | | | iterable object. I'm not sure how that got overlooked before! Got rid of the internal _PySequence_IterContains, introduced a new internal _PySequence_IterSearch, and rewrote all the iteration-based "count of", "index of", and "is the object in it or not?" routines to just call the new function. I suppose it's slower this way, but the code duplication was getting depressing.
* PyClass_New(): put the extended Don Beaudry hook back in. When one ofGuido van Rossum2001-09-071-4/+14
| | | | | | | | | | | | | | | | the base classes is not a classic class, and its class (the metaclass) is callable, call the metaclass to do the deed. One effect of this is that, when mixing classic and new-style classes amongst the bases of a class, it doesn't matter whether the first base class is a classic class or not: you will always get the error "TypeError: metatype conflict among bases". (Formerly, with a classic class first, you'd get "TypeError: PyClass_New: base must be a class".) Another effect is that multiple inheritance from ExtensionClass.Base, with a classic class as the first class, transfers control to the ExtensionClass.Base class. This is what we need for SF #443239 (and also for running Zope under 2.2a4, before ExtensionClass is replaced).
* PySequence_Check(), PyMapping_Check(): only return true if theGuido van Rossum2001-09-071-2/+4
| | | | | | | | | | | | | | | corresponding "getitem" operation (sq_item or mp_subscript) is implemented. I realize that "sequence-ness" and "mapping-ness" are poorly defined (and the tests may still be wrong for user-defined instances, which always have both slots filled), but I believe that a sequence that doesn't support its getitem operation should not be considered a sequence. All other operations are optional though. For example, the ZODB BTree tests crashed because PySequence_Check() returned true for a dictionary! (In 2.2, the dictionary type has a tp_as_sequence pointer, but the only field filled is sq_contains, so you can write "if key in dict".) With this fix, all standalone ZODB tests succeed.
* PyType_IsSubtype(): test tp_flags for HAVE_CLASS bit before accessingGuido van Rossum2001-09-071-0/+3
| | | | | | | | | | | | a->tp_mro. If a doesn't have class, it's considered a subclass only of itself or of 'object'. This one fix is enough to prevent the ExtensionClass test suite from dumping core, but that doesn't say much (it's a rather small test suite). Also note that for ExtensionClass-defined types, a different subclass test may be needed. But I haven't checked whether PyType_IsSubtype() is actually used in situations where this matters -- probably it doesn't, since we also don't check for classic classes.
* long_true_divide: reliably force underflow to 0 when the denominatorTim Peters2001-09-061-0/+2
| | | | | | has more bits than the numerator than can be counted in a C int (yes, that's unlikely, and no, I'm not adding a test case with a 2 gigabit long).
* Rename 'getset' to 'property'.Guido van Rossum2001-09-061-23/+23
|
* Revert parts of patch #453627, documenting the resulting test failuresMartin v. Löwis2001-09-061-17/+1
| | | | instead.
* Enable large file support on Win32 systems.Tim Peters2001-09-061-1/+1
| | | | | | | | | Curious: the MS docs say stati64 etc are supported even on Win95, but Win95 doesn't support a filesystem that allows partitions > 2 Gb. test_largefile: This was opening its test file in text mode. I have no idea how that worked under Win64, but it sure needs binary mode on Win98. BTW, on Win98 test_largefile runs quickly (under a second).
* Better error msg for 3-arg pow with a float argument.Tim Peters2001-09-051-1/+1
|
generated by cgit v0.12 at 2025-01-30 23:39:22 (GMT)