This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: complex() comments wrongly say it supports NaN and inf
Type: Stage:
Components: Documentation Versions: Python 2.7
process
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: docs@python Nosy List: dalke, docs@python, mark.dickinson
Priority: normal Keywords:

Created on 2011-01-02 21:21 by dalke, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (2)
msg125104 - (view) Author: Andrew Dalke (dalke) * (Python committer) Date: 2011-01-02 21:21
complex("nan") raises "ValueError: complex() arg is a malformed string"  while complex(float("nan")) returns (nan+0j). This was reported in http://bugs.python.org/issue2121 with the conclusion "wont fix".

complex("inf") has the same behaviors.

The implementation in complexobject.c says 


    /* a valid complex string usually takes one of the three forms:

         <float>                  - real part only
         <float>j                 - imaginary part only
         <float><signed-float>j   - real and imaginary parts

       where <float> represents any numeric string that's accepted by the
       float constructor (including 'nan', 'inf', 'infinity', etc.), and
       <signed-float> is any string of the form <float> whose first
       character is '+' or '-'.

This comment is wrong and it distracted me for a while as I tried to figure out why complex("nan") wasn't working. It should be fixed, with the word "including" replaced by "excluding".

I don't have a real need for complex("nan") support - this was of intellectual interest only. Also of intellectual interest, PyPy 1.4 does accept complex("nan") but converts complex("nan+nanj") to (nannanj), so it suffers from the strange corner cases which Raymond points out when advocating for "wont fix."

Because
msg125147 - (view) Author: Andrew Dalke (dalke) * (Python committer) Date: 2011-01-03 01:31
Well that's ... interesting. While I compiled 2.7 and was looking at the 2.7 code my tests were against 2.6. 


Python 2.7 (trunk:74969:87651M, Jan  2 2011, 21:58:12) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> complex("nan-nanj")
(nan+nanj)
>>> 

This means that the comments are correct and the error was in my understanding, as influenced by issue2121.

I therefore closed this.
History
Date User Action Args
2022-04-11 14:57:10adminsetgithub: 55018
2011-01-03 21:01:18mark.dickinsonsetnosy: + mark.dickinson
2011-01-03 01:31:42dalkesetstatus: open -> closed

messages: + msg125147
resolution: out of date
nosy: dalke, docs@python
2011-01-02 21:21:30dalkecreate