Rob Renaud added the comment:
I am totally new to Python dev. I reinvented a NamedTupleReader
tonight, only to find out that it was created a year ago. My primary
motivation is that DictReader reads headers nicely, but DictWriter
totally sucks at handling them.
Consider doing some filtering
Rob Renaud added the comment:
My previous patch could write the header twice. But I am not sure about
about how the writer should handle the fieldnames parameter on one hand,
and the namedtuple._fields on the other.
Added file: http://bugs.python.org/file13188/named_tuple_write_header2.patch
Changes by Rob Renaud :
Removed file: http://bugs.python.org/file13187/named_tuple_write_header.patch
___
Python tracker
<http://bugs.python.org/issue1818>
___
___
Pytho
Rob Renaud added the comment:
I want to make sure I understand. Am I correct in believing that Skip
thinks writing headers should be optional, while Jervis believes we
should leave the burden to the NamedTupleWriter client?
I agree that we should not unconditionally write headers, but I
Rob Renaud added the comment:
I did a search on Google code for the DictReader constructor. I
analyzed the first 3 pages, the fieldnames parameter was used in 14 of
27 cases (discounting unittest code built into Python) and was not
used in 13 of 27 cases. I suppose that means headered csv
Rob Renaud added the comment:
I found this via google search when disappointed that random.choice
raised an exception rather than returned a random item in the set.
It's quite easy to implement random.choice for sets/dicts in O(1)
expected time from the C implementation as long as the set
