Commit Graph

112 Commits

Author SHA1 Message Date
Mark Dickinson 82b34c5dbe Issue #5211: Fix complex type to avoid implicit calls to
complex.__coerce__.  Thanks Meador Inge for the patch.
2010-02-21 12:57:35 +00:00
Benjamin Peterson 3694366af5 factor out __complex__ lookup code to fix another case 2010-01-04 01:00:47 +00:00
Benjamin Peterson ecdae19fbe do correct lookup of the __complex__ method 2010-01-04 00:43:01 +00:00
Mark Dickinson 31f0cfef0e Include ieeefp.h (when available) in pyport.h instead of individually in
Objects/floatobject.c and Objects/complexobject.c.  This should silence
compiler warnings about implicit declaration of the 'finite' function
on Solaris.
2009-11-28 12:30:36 +00:00
Mark Dickinson c04c7c5b72 Issue #7117: Use PyOS_string_to_double instead of PyOS_ascii_strtod in
complexobject.c.  Also remove length restriction on unicode inputs to
the complex constructor.
2009-10-26 22:28:14 +00:00
Mark Dickinson a4e0efa4b1 Issue #5829: don't raise OverflowError for complex('1e500'). Backport of r72803. 2009-05-20 18:43:07 +00:00
Mark Dickinson 50626db437 Issue #6044: remove confusing wording from complex -> integer and
complex -> float conversion error messages.
2009-05-17 10:38:30 +00:00
Eric Smith a985a3aee4 Issue #5920: Changed format.__float__ and complex.__float__ to use a precision of 12 when using the empty presentation type. This more closely matches str()'s behavior and reduces surprises when adding alignment flags to an empty format string. Patch by Mark Dickinson. 2009-05-05 18:26:08 +00:00
Mark Dickinson 777e4ff503 Eliminate some locale-dependent calls to isspace and tolower. 2009-05-03 20:59:48 +00:00
Eric Smith 9139cc6a3b Issue #1588: Add complex.__format__. 2009-04-30 00:58:58 +00:00
Mark Dickinson 944c6aedd0 Reset errno before both calls to PyOS_ascii_strtod, not just one. 2009-04-26 14:00:08 +00:00
Mark Dickinson 0a6501bf56 Fix typo in complex parsing code; expand tests. 2009-04-25 09:47:00 +00:00
Mark Dickinson 90d47cb46c Fix missing 'return NULL' 2009-04-24 13:14:07 +00:00
Mark Dickinson 95bc980d9e Issue #5816:
- simplify parsing and printing of complex numbers
 - make complex(repr(z)) round-tripping work for complex
   numbers involving nans, infs, or negative zeros
 - don't accept some of the stranger complex strings
   that were previously allowed---e.g., complex('1..1j')
2009-04-24 12:46:53 +00:00
Gregory P. Smith dd96db63f6 This reverts r63675 based on the discussion in this thread:
http://mail.python.org/pipermail/python-dev/2008-June/079988.html

Python 2.6 should stick with PyString_* in its codebase.  The PyBytes_* names
in the spirit of 3.0 are available via a #define only.  See the email thread.
2008-06-09 04:58:54 +00:00
Alexandre Vassalotti 80af6da748 Fixed complex.__getnewargs__() to not emit another complex object. 2008-06-04 20:41:44 +00:00
Christian Heimes 593daf545b Renamed PyString to PyBytes 2008-05-26 12:51:38 +00:00
Christian Heimes 6f34109384 I finally got the time to update and merge Mark's and my trunk-math branch. The patch is collaborated work of Mark Dickinson and me. It was mostly done a few months ago. The patch fixes a lot of loose ends and edge cases related to operations with NaN, INF, very small values and complex math.
The patch also adds acosh, asinh, atanh, log1p and copysign to all platforms. Finally it fixes differences between platforms like different results or exceptions for edge cases. Have fun :)
2008-04-18 23:13:07 +00:00
Neal Norwitz 9fdfaaf9af Fix compiler warning about finite() missing on Solaris. 2008-03-28 05:34:59 +00:00
Christian Heimes 2f0da53d28 Fixed repr() and str() of complex numbers. Complex suffered from the same problem as floats but I forgot to test and fix them. 2008-02-15 06:57:08 +00:00
Christian Heimes d7e1b2bd17 static PyObject* variables should use PyString_InternFromString() instead of PyObject_FromString() to store a python string in a function level static var. 2008-01-28 02:07:53 +00:00
Georg Brandl 96f2184de6 Indentation normalization. 2008-01-19 10:18:07 +00:00
Jeffrey Yasskin 2f3c16be73 Backport PEP 3141 from the py3k branch to the trunk. This includes r50877 (just
the complex_pow part), r56649, r56652, r56715, r57296, r57302, r57359, r57361,
r57372, r57738, r57739, r58017, r58039, r58040, and r59390, and new
documentation. The only significant difference is that round(x) returns a float
to preserve backward-compatibility. See http://bugs.python.org/issue1689.
2008-01-03 02:21:52 +00:00
Guido van Rossum e227263a6c Shut up a compiler warning. 2007-12-03 22:02:10 +00:00
Guido van Rossum 715ec1818d Patch # 1507 by Mark Dickinson. Make complex(x, -0) retain the sign of
the imaginary part (as long as it's not complex).
Backport candidate?
2007-11-27 22:38:36 +00:00
Brett Cannon 0153159e67 Add a bunch of GIL release/acquire points in tp_print implementations and for
PyObject_Print().

Closes issue #1164.
2007-09-17 03:28:34 +00:00
Martin v. Löwis 6819210b9e PEP 3123: Provide forward compatibility with Python 3.0, while keeping
backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and
PyVarObject_HEAD_INIT.
2007-07-21 06:55:02 +00:00
Georg Brandl 2b869943fa Patch #1675423: PyComplex_AsCComplex() now tries to convert an object
to complex using its __complex__() method before falling back to the
__float__() method. Therefore, the functions in the cmath module now
can operate on objects that define a __complex__() method.
 (backport)
2007-03-17 16:08:45 +00:00
Georg Brandl 8f032cbb05 Patch #1642844: comments to clarify the complexobject constructor. 2007-03-13 07:57:51 +00:00
Collin Winter e38051db87 Patch #1491866: change the complex() constructor to allow parthensized forms. This means complex(repr(x)) now works instead of raising a ValueError. 2007-03-09 20:33:07 +00:00
Neal Norwitz 0593de32d9 Fix SF #1676971, Complex OverflowError has a typo 2007-03-09 05:59:01 +00:00
Neal Norwitz 4b0a315c31 Use sizeof(buffer) instead of duplicating the constants to ensure they won't
be wrong.

The real change is to pass (bufsz - 1) to PyOS_ascii_formatd and 1
to strncat.  strncat copies n+1 bytes from src (not dest).

Reported by Klocwork #58.
2006-07-16 02:22:30 +00:00
Georg Brandl 6b50c63a23 Correctly allocate complex types with tp_alloc. (bug #1498638) 2006-06-01 08:27:32 +00:00
Skip Montanaro 429433b30b C++ compiler cleanup: bunch-o-casts, plus use of unsigned loop index var in a couple places 2006-04-18 00:35:43 +00:00
Georg Brandl 347b30042b Remove unnecessary casts in type object initializers. 2006-03-30 11:57:00 +00:00
Martin v. Löwis 15e62742fa Revert backwards-incompatible const changes. 2006-02-27 16:46:16 +00:00
Martin v. Löwis 18e165558b Merge ssize_t branch. 2006-02-15 17:27:45 +00:00
Jeremy Hylton af68c874a6 Add const to several API functions that take char *.
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 *.
2005-12-10 18:50:16 +00:00
Georg Brandl c404ff2f2d patch [ 1118729 ] Error in representation of complex numbers(again) 2005-09-16 06:42:26 +00:00
Raymond Hettinger 5d01aa4f6a Bug #1079011: Incorrect error message (somewhat) 2004-12-19 20:45:20 +00:00
Martin v. Löwis 70aa1f2095 Fix repr for negative imaginary part. Fixes #1013908. 2004-08-22 21:09:15 +00:00
Martin v. Löwis 737ea82a5a Patch #774665: Make Python LC_NUMERIC agnostic. 2004-06-08 18:52:54 +00:00
Raymond Hettinger 8ae4689657 Simplify and speedup uses of Py_BuildValue():
* 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)
2003-10-12 19:09:37 +00:00
Raymond Hettinger 0970dbab97 Remove 'e.g.' from error message 2003-08-30 23:57:36 +00:00
Tim Peters 465fa3dac4 complex_new(): This could leak when the argument was neither string nor
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>).
2003-08-15 01:16:37 +00:00
Walter Dörwald 5ecd6c4db2 Fix typo in comment. 2003-06-17 20:22:24 +00:00
Guido van Rossum 4eadfa2b2e Fix from Greg Chapman from SF bug #695651: a complex subclass
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.
2003-03-02 13:51:47 +00:00
Guido van Rossum 5d9113d8be Implement appropriate __getnewargs__ for all immutable subclassable builtin
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.
2003-01-29 17:58:45 +00:00
Raymond Hettinger 604cd6ae79 complex() was the only numeric constructor that created a new instance
when given its own type as an argument.
2002-08-29 14:22:51 +00:00
Guido van Rossum e3a8e7ed1d Call me anal, but there was a particular phrase that was speading to
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.
2002-08-19 19:26:42 +00:00