Reproduction depends on the quoting.
QUOTE_ALL
import csv
data = [1, 1j]
with open('example.csv', 'w') as f:
writer = csv.writer(f, quoting=csv.QUOTE_ALL)
writer.writerow(data)
with open('example.csv') as f:
contents = f.read()
print(contents) # 1,1j
reader = csv.reader(contents, quoting=csv.QUOTE_ALL)
print(list(reader)) # [['1'], ['', ''], ['1'], ['j'], []]
In this case, we don't have our data back, but at least it does not raise.
QUOTE_NONNUMERIC
Qouting docs:
No automatic data type conversion is performed unless the QUOTE_NONNUMERIC format option is specified (in which case unquoted fields are transformed into floats)
import csv
data = [1, 1j]
with open('example.csv', 'w') as f:
writer = csv.writer(f, quoting=csv.QUOTE_NONNUMERIC)
writer.writerow(data)
with open('example.csv') as f:
contents = f.read()
print(contents) # 1,1j
reader = csv.reader(contents, quoting=csv.QUOTE_NONNUMERIC)
print(list(reader))
# Traceback (most recent call last):
# File "/Users/sobolev/Desktop/cpython/ex.py", line 11, in <module>
# print(list(reader))
# ^^^^^^^^^^^^
# ValueError: could not convert string to float: 'j'
In this case, it raises an error, while trying to convert 1j to float.
Current docs / tests
I cannot find any mentions of complex numbers in tests or docs for csv.
Solutions?
- We can say that it works as expected: with this strange
QUOTE_ALL formatting and QUOTE_NONNUMERIC exception. Add a test case for it and forget about it
- We can try to quote
complex as string: in this case it will be treated as "1j". I think it is much better, because it will allow users to convert this value to complex manually
- Forbid writting
complex numbers. However, I don't think it is a path we should go
Reproduction depends on the quoting.
QUOTE_ALL
In this case, we don't have our data back, but at least it does not raise.
QUOTE_NONNUMERIC
Qouting docs:
In this case, it raises an error, while trying to convert
1jtofloat.Current docs / tests
I cannot find any mentions of
complexnumbers in tests or docs forcsv.Solutions?
QUOTE_ALLformatting andQUOTE_NONNUMERICexception. Add a test case for it and forget about itcomplexas string: in this case it will be treated as"1j". I think it is much better, because it will allow users to convert this value tocomplexmanuallycomplexnumbers. However, I don't think it is a path we should go