| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
| |
- 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')
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
| |
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 :)
|
| |
|
|
|
|
| |
problem as floats but I forgot to test and fix them.
|
|
|
|
| |
PyObject_FromString() to store a python string in a function level static var.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
the imaginary part (as long as it's not complex).
Backport candidate?
|
|
|
|
|
|
| |
PyObject_Print().
Closes issue #1164.
|
|
|
|
|
| |
backwards compatibility. Add Py_Refcnt, Py_Type, Py_Size, and
PyVarObject_HEAD_INIT.
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
| |
forms. This means complex(repr(x)) now works instead of raising a ValueError.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
a couple places
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 *.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
* 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)
|
| |
|
|
|
|
|
|
| |
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>).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
when given its own type as an argument.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
pyconfig.h.
|
|
|
|
|
| |
Made conversion failure error messages consistent between types.
Added related unittests.
|
|
|
|
| |
is the same in all three cases (mostly because // calls divmod :-).
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
|
| |
complex_subtype_from_string(): this stopped parsing at the first 0
byte, as if that were the end of the input string.
Bugfix candidate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
This fixes SF bug #514858 (Gregory Smith): complex not entirely
immutable
2.2.1 Bugfix candidate!
|
|
|
|
|
| |
and only if there is no second arg.
This closes SF patch #479551.
|
|
|
|
|
|
|
| |
sprintf() to PyOS_snprintf() for buffer overrun avoidance.
complex_print(), complex_repr(), complex_str(): Call complex_to_buf()
passing in sizeof(buf).
|