summaryrefslogtreecommitdiffstats
path: root/Objects/complexobject.c
Commit message (Collapse)AuthorAgeFilesLines
* C++ compiler cleanup: bunch-o-casts, plus use of unsigned loop index var in ↵Skip Montanaro2006-04-181-1/+1
| | | | a couple places
* Remove unnecessary casts in type object initializers.Georg Brandl2006-03-301-5/+5
|
* Revert backwards-incompatible const changes.Martin v. Löwis2006-02-271-1/+1
|
* Merge ssize_t branch.Martin v. Löwis2006-02-151-2/+2
|
* Add const to several API functions that take char *.Jeremy Hylton2005-12-101-1/+1
| | | | | | | | | | | | | | | | | | | In C++, it's an error to pass a string literal to a char* function without a const_cast(). Rather than require every C++ extension module to put a cast around string literals, fix the API to state the const-ness. I focused on parts of the API where people usually pass literals: PyArg_ParseTuple() and friends, Py_BuildValue(), PyMethodDef, the type slots, etc. Predictably, there were a large set of functions that needed to be fixed as a result of these changes. The most pervasive change was to make the keyword args list passed to PyArg_ParseTupleAndKewords() to be a const char *kwlist[]. One cast was required as a result of the changes: A type object mallocs the memory for its tp_doc slot and later frees it. PyTypeObject says that tp_doc is const char *; but if the type was created by type_new(), we know it is safe to cast to char *.
* patch [ 1118729 ] Error in representation of complex numbers(again)Georg Brandl2005-09-161-6/+3
|
* Bug #1079011: Incorrect error message (somewhat)Raymond Hettinger2004-12-191-1/+1
|
* Fix repr for negative imaginary part. Fixes #1013908.Martin v. Löwis2004-08-221-2/+6
|
* Patch #774665: Make Python LC_NUMERIC agnostic.Martin v. Löwis2004-06-081-9/+14
|
* Simplify and speedup uses of Py_BuildValue():Raymond Hettinger2003-10-121-2/+2
| | | | | | * Py_BuildValue("(OOO)",a,b,c) --> PyTuple_Pack(3,a,b,c) * Py_BuildValue("()",a) --> PyTuple_New(0) * Py_BuildValue("O", a) --> Py_INCREF(a)
* Remove 'e.g.' from error messageRaymond Hettinger2003-08-301-3/+3
|
* complex_new(): This could leak when the argument was neither string norTim Peters2003-08-151-0/+3
| | | | | | number. This accounts for the 2 refcount leaks per test_complex run Michael Hudson discovered (I figured only I would have the stomach to look for leaks in floating-point code <wink>).
* Fix typo in comment.Walter Dörwald2003-06-171-1/+1
|
* Fix from Greg Chapman from SF bug #695651: a complex subclassGuido van Rossum2003-03-021-2/+3
| | | | | | | | | | | | | | constructor, when passed a single complex argument, returns the argument unchanged. This should be done only for the complex base class; a complex subclass should of course cast the value to the subclass in this case. The fix also revealed a segfault in complex_getnewargs(): the argument for the Py_BuildValue() format code "D" is the *address* of a Py_complex struct, not the value. (This corroborated by the API documentation.) I expect this needs to be backported to 2.2.3.
* Implement appropriate __getnewargs__ for all immutable subclassable builtinGuido van Rossum2003-01-291-0/+7
| | | | | | | | types. The special handling for these can now be removed from save_newobj(). Add some testing for this. Also add support for setting the 'fast' flag on the Python Pickler class, which suppresses use of the memo.
* complex() was the only numeric constructor that created a new instanceRaymond Hettinger2002-08-291-0/+9
| | | | when given its own type as an argument.
* Call me anal, but there was a particular phrase that was speading toGuido van Rossum2002-08-191-1/+1
| | | | | | | comments everywhere that bugged me: /* Foo is inlined */ instead of /* Inline Foo */. Somehow the "is inlined" phrase always confused me for half a second (thinking, "No it isn't" until I added the missing "here"). The new phrase is hopefully unambiguous.
* Patch #568124: Add doc string macros.Martin v. Löwis2002-06-131-2/+2
|
* Rearrange the #ifndef WITHOUT_COMPLEX so it can be picked up fromGuido van Rossum2002-06-131-2/+2
| | | | pyconfig.h.
* Close SF bug 563740. complex() now finds __complex__() in new style classes.Raymond Hettinger2002-06-061-26/+23
| | | | | Made conversion failure error messages consistent between types. Added related unittests.
* Deprecate % as well. The message for deprecation of //, % and divmodGuido van Rossum2002-04-151-1/+6
| | | | is the same in all three cases (mostly because // calls divmod :-).
* SF bug #543387.Guido van Rossum2002-04-151-0/+5
| | | | | | | | | Complex numbers implement divmod() and //, neither of which makes one lick of sense. Unfortunately this is documented, so I'm adding a deprecation warning now, so we can delete this silliness, oh, around 2005 or so. Bugfix candidate (At least for 2.2.2, I think.)
* SF bug 543840: complex(string) accepts strings with \0Tim Peters2002-04-141-1/+1
| | | | | | | complex_subtype_from_string(): this stopped parsing at the first 0 byte, as if that were the end of the input string. Bugfix candidate.
* PyObject_Del can now be used as a function designator.Neil Schemenauer2002-04-121-1/+1
|
* SF bug 533198: Complex power underflow raises exception.Tim Peters2002-03-221-3/+9
| | | | | | | | | | | | | | | | | | | | | | | Konrad was too kind. Not only did it raise an exception, the specific exception it raised made no sense. These are old bugs in complex_pow() and friends: 1. Raising 0 to a negative power isn't a range error, it's a domain error, so changed c_pow() to set errno to EDOM in that case instead of ERANGE. 2. Changed complex_pow() to: A. Used the Py_ADJUST_ERANGE2 macro to try to clear errno of a spurious ERANGE error due to underflow in the libm pow() called by c_pow(). B. Produced different exceptions depending on the errno value: i) For errno==EDOM, raise ZeroDivisionError instead of ValueError. This is for consistency with the non-complex cases 0.0**-2 and 0**-2 and 0L**-2. ii) For errno==ERANGE, raise OverflowError. Bugfix candidate.
* Declare real and imag as read-only attributes.Guido van Rossum2002-02-081-2/+2
| | | | | | | This fixes SF bug #514858 (Gregory Smith): complex not entirely immutable 2.2.1 Bugfix candidate!
* Ensure that complex() only accepts a string argument as the first arg,Fred Drake2001-12-131-1/+13
| | | | | and only if there is no second arg. This closes SF patch #479551.
* complex_to_buf(), complex_subtype_from_c_complex(): Conversion ofBarry Warsaw2001-11-281-8/+10
| | | | | | | sprintf() to PyOS_snprintf() for buffer overrun avoidance. complex_print(), complex_repr(), complex_str(): Call complex_to_buf() passing in sizeof(buf).
* complex_subtype_from_string(): move the declaration of s_buffer[] outGuido van Rossum2001-10-251-1/+3
| | | | | | | | of the if block where it was before. The name is only used inside that if block, but the storage is referenced outside it via the 's' variable. (This patch was part of SF patch #474590 -- RISC OS support.)
* Enable GC for new-style instances. This touches lots of files, sinceGuido van Rossum2001-10-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | many types were subclassable but had a xxx_dealloc function that called PyObject_DEL(self) directly instead of deferring to self->ob_type->tp_free(self). It is permissible to set tp_free in the type object directly to _PyObject_Del, for non-GC types, or to _PyObject_GC_Del, for GC types. Still, PyObject_DEL was a tad faster, so I'm fearing that our pystone rating is going down again. I'm not sure if doing something like void xxx_dealloc(PyObject *self) { if (PyXxxCheckExact(self)) PyObject_DEL(self); else self->ob_type->tp_free(self); } is any faster than always calling the else branch, so I haven't attempted that -- however those types whose own dealloc is fancier (int, float, unicode) do use this pattern.
* Merge branch changes (coercion, rich comparisons) into trunk.Guido van Rossum2001-09-271-4/+2
|
* Do the same thing to complex that I did to str: the rich comparisonGuido van Rossum2001-09-241-7/+10
| | | | | function returns NotImplemented when comparing objects whose tp_richcompare slot is not itself.
* Add optional docstrings to member descriptors. For backwardsGuido van Rossum2001-09-201-3/+5
| | | | | | | | | | | | | | | compatibility, this required all places where an array of "struct memberlist" structures was declared that is referenced from a type's tp_members slot to change the type of the structure to PyMemberDef; "struct memberlist" is now only used by old code that still calls PyMember_Get/Set. The code in PyObject_GenericGetAttr/SetAttr now calls the new APIs PyMember_GetOne/SetOne, which take a PyMemberDef argument. As examples, I added actual docstrings to the attributes of a few types: file, complex, instance method, super, and xxsubtype.spamlist. Also converted the symtable to new style getattr.
* complex_coerce(): add explicit PyComplex_Check() test. Previously,Guido van Rossum2001-09-191-0/+5
| | | | | | | | complex_coerce() would never be called with a complex argument, because PyNumber_Coerce[Ex] doesn't bother calling the type's coercion method if the values already have the same type. But now, of course, it's possible to pass an instance of a complex *subtype*, and those must be accepted.
* Again perhaps the end of [#460020] bug or feature: unicode() and subclasses.Tim Peters2001-09-121-11/+19
| | | | | Inhibited complex unary plus optimization when applied to a complex subtype. Added PyComplex_CheckExact macro. Some comments and minor code fiddling.
* Revert parts of patch #453627, documenting the resulting test failuresMartin v. Löwis2001-09-061-17/+1
| | | | instead.
* Patch #453627: Define the following macros when compiling on a UnixWare 7.x ↵Martin v. Löwis2001-09-051-1/+17
| | | | | | | system: SCO_ATAN2_BUG, SCO_ACCEPT_BUG, and STRICT_SYSV_CURSES. Work aroudn a bug in the SCO UnixWare atan2() implementation.
* Raise OverflowError when appropriate on long->float conversion. Most ofTim Peters2001-09-041-0/+2
| | | | | | | the fiddling is simply due to that no caller of PyLong_AsDouble ever checked for failure (so that's fixing old bugs). PyLong_AsDouble is much faster for big inputs now too, but that's more of a happy consequence than a design goal.
* PEP 238 documented -Qwarn as warning only for classic int or longGuido van Rossum2001-09-041-1/+1
| | | | | division, and this makes sense. Add -Qwarnall to warn for all classic divisions, as required by the fixdiv.py tool.
* Add warning mode for classic division, almost exactly as specified inGuido van Rossum2001-08-311-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Patch #445762: Support --disable-unicodeMartin v. Löwis2001-08-171-1/+3
| | | | | | | | - 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.
* Patch #427190: Implement and use METH_NOARGS and METH_O.Martin v. Löwis2001-08-161-4/+2
|
* Implement PEP 238 in its (almost) full glory.Guido van Rossum2001-08-081-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | This introduces: - A new operator // that means floor division (the kind of division where 1/2 is 0). - The "future division" statement ("from __future__ import division) which changes the meaning of the / operator to implement "true division" (where 1/2 is 0.5). - New overloadable operators __truediv__ and __floordiv__. - New slots in the PyNumberMethods struct for true and floor division, new abstract APIs for them, new opcodes, and so on. I emphasize that without the future division statement, the semantics of / will remain unchanged until Python 3.0. Not yet implemented are warnings (default off) when / is used with int or long arguments. This has been on display since 7/31 as SF patch #443474. Flames to /dev/null.
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-13/+290
|
* SF bug [ #409448 ] Complex division is braindeadTim Peters2001-03-181-8/+58
| | | | | | http://sourceforge.net/tracker/?func=detail&aid=409448&group_id=5470&atid=105470 Now less braindead. Also added test_complex.py, which doesn't test much, but fails without this patch.
* When 1.6 boosted the # of digits produced by repr(float), repr(complex)Tim Peters2001-03-111-8/+32
| | | | apparently forgot to play along. Make complex act like float.
* Use rich comparisons to fulfill an old wish: complex numbers now raiseGuido van Rossum2001-01-181-49/+84
| | | | | | | | | | | exceptions when compared using <, <=, > or >=. NOTE: This is a tentative change: this means that cmp() involving complex numbers will raise an exception when the numbers differ, and that in turn means that e.g. dictionaries and certain other compounds (e.g. UserLists) containing complex numbers can't be compared either. So we'll have to decide whether this is acceptable. The alpha test cycle is a good time to keep an eye on this!
* Rationalize use of limits.h, moving the inclusion to Python.h.Fred Drake2000-09-261-4/+0
| | | | | | | | Add definitions of INT_MAX and LONG_MAX to pyport.h. Remove includes of limits.h and conditional definitions of INT_MAX and LONG_MAX elsewhere. This closes SourceForge patch #101659 and bug #115323.
* REMOVED all CWI, CNRI and BeOpen copyright markings.Guido van Rossum2000-09-011-9/+0
| | | | This should match the situation in the 1.6b1 tree.
* Fix for http://sourceforge.net/bugs/?func=detailbug&bug_id=111866&group_id=5470.Tim Peters2000-08-151-46/+17
| | | | | | | | | | | This was a misleading bug -- the true "bug" was that hash(x) gave an error return when x is an infinity. Fixed that. Added new Py_IS_INFINITY macro to pyport.h. Rearranged code to reduce growing duplication in hashing of float and complex numbers, pushing Trent's earlier stab at that to a logical conclusion. Fixed exceedingly rare bug where hashing of floats could return -1 even if there wasn't an error (didn't waste time trying to construct a test case, it was simply obvious from the code that it *could* happen). Improved complex hash so that hash(complex(x, y)) doesn't systematically equal hash(complex(y, x)) anymore.
generated by cgit v0.12 at 2024-10-23 15:28:49 (GMT)