Here's a proof-of-concept patch.  If approved, will change from
generator form to match the other readers and will add a test suite.

The idea corresponds to what is currently done by the dict reader but
returns a space and time efficient named tuple instead of a dict.  Field
order is preserved and named attribute access is supported.

A writer is not needed because named tuples can be feed into the
existing writer just like regular tuples.

Barry, any thoughts on this?

I'd personally be kind of surprised if Barry had any thoughts on this.
Is there any reason this couldn't be pushed down into the C code and
replace the normal tuple output completely?  In the absence of any
fieldnames you could just dream some up, like "field001", "field002",
etc.

Skip

An implementation of a namedtuple reader and writer.

Created a writer for the case where user would like to specify
desired field names and default values on missing field names.

e.g.
mywriter = NamedTupleWriter(f, fieldnames=['f1', 'f2', 'f3'], 
                            restval='missing')

Nt = namedtuple('LessFields', 'f1 f3')
nt = Nt(f1='one', f2=2)

mywriter.writerow(nt) # writes one,missing,2

any thoughts on case where defined fieldname has a leading 
underscore? Should there be a flag to silently ignore? 

e.g. 
if self._ignore_underscores:
   fieldname = fieldname.lstrip('_')

Leading underscores may be present in an unsighted csv file,
additionally, spaces and other non alpha numeric characters pose 
a problem that does not affect the DictReader class. 

Cheers,

Consider providing a hook to a function that converts non-conforming
field names (ones with a leading underscore, leading digit, non-letter,
keyword, or duplicate name).

class NamedTupleReader:
    def __init__(self, f, fieldnames=None, restkey=None, restval=None,
                 dialect="excel", fieldnamer=None, *args, **kwds):
                 . . .

I'm going to either post a recipe to do the renaming or provide a static
method for the same purpose.   It might work like this:

  >>> renamer(['abc', 'def', '1', '_hidden', 'abc', 'p', 'abc'])
  ['abc', 'x_def', 'x_1', 'x_hidden', 'x_abc', 'p', 'x1_abc']

In r69480, named tuples gained the ability to automatically rename
invalid fieldnames.

Updated NamedTupleReader to give a rename=False keyword argument.
rename is passed directly to the namedtuple factory function to enable
automatic handling of invalid fieldnames.

Two new tests for the rename keyword.

Cheers,

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 on a csv file, like so.

sample_data = [
    'title,latitude,longitude',
    'OHO Ofner & Hammecke Reinigungsgesellschaft mbH,48.128265,11.610848',
    'Kitchen Kaboodle,45.544241,-122.715728',
    'Walgreens,28.339727,-81.596367',
    'Gurnigel Pass,46.731944,7.447778'
    ]

def filter_with_dict_reader_writer():
  accepted_rows = []
  for row in csv.DictReader(sample_data):
    if float(row['latitude']) > 0.0 and float(row['longitude']) > 0.0:
      accepted_rows.append(row)

  field_names = csv.reader(sample_data).next()
  output_writer = csv.DictWriter(open('accepted_by_dict.csv', 'w'),
                                 field_names)
  output_writer.writerow(dict(zip(field_names, field_names)))
  output_writer.writerows(accepted_rows)

You have to work so hard to maintain the headers when you write the file
with DictWriter.  I understand this is a limitation of dicts throwing
away the order information.  But namedtuples don't have that problem.

NamedTupleReader and NamedTupleWriter should be inverses.  This means
that NamedTupleWriter needs to write headers.  This should produce
identical output as the dict writer example, but it's much cleaner.

def filter_with_named_tuple_reader_writer():
   accepted_rows = []
   for row in csv.NamedTupleReader(sample_data):
     if float(row.latitude) > 0.0 and float(row.longitude) > 0.0:
       accepted_rows.append(row)

   output_writer = csv.NamedTupleWriter(
       open('accepted_by_named_tuple.csv', 'w'))
   output_writer.writerows(accepted_rows)

I patched on top of the existing NamedTupleWriter patch adding support
for writing headers.  I don't know if that's bad style/etiquette, etc.

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.

The two latest patches (ntreader4.diff and
named_tuple_write_header.patch) seem like they are going in the right
direction and are getting close.

Barry or Skip, is this something you want in your module?

Raymond> Barry or Skip, is this something you want in your module?

Sorry, I haven't really looked at this ticket other than to notice its
presence.  I wrote the DictReader/DictWriter functions way back when, so I'm
pretty comfortable using them.  I haven't felt the need for any other reader
or writer which manipulates file headers.

Skip

I think it would be useful to have.

Hrm... I replied twice by email.  Only one comment appears to have
survived the long trip.  Here's my second reply:


    Rob> NamedTupleReader and NamedTupleWriter should be inverses.  This
    Rob> means that NamedTupleWriter needs to write headers.  This should
    Rob> produce identical output as the dict writer example, but it's much
    Rob> cleaner.

You're assuming that one instance of these classes will read or write an
entire file.  What if you want to append lines to an existing CSV file or
pick up reading a file with a new reader which has already be partially
processed?

Let me be more explicit.  I don't know how it implements it, but I think
you really need to give the user the option of specifying the field
names and not reading/writing headers.  It can't be implicit as I
interpreted Rob's earlier comment:

    > NamedTupleReader and NamedTupleWriter should be inverses.
    > This means that NamedTupleWriter needs to write headers.

Skip

Skip> Let me be more explicit.  I don't know how it implements it, but I 
think
Skip> you really need to give the user the option of specifying the 
field
Skip> names and not reading/writing headers.  It can't be implicit as I
Skip> interpreted Rob's earlier comment:

    rrenaud> NamedTupleReader and NamedTupleWriter should be inverses.
    rrenaud> This means that NamedTupleWriter needs to write headers.

I agree with Skip, we mustn't have a 'wroteheader' flag internal to the 
NamedTupleWriter.

Currently to write a 'header' row with a csv.writer you could (for 
example) pass a tuple of header names to writerow. NamedTupleWriter
is no different, you would have a namedtuple of header names instead of
a tuple of header names.

I would not like to see another flag added to the initialisation process
to enable the writing of a header row as the 'first' (or any) row 
written to a file.  We could add a function 'writeheader' that would
write the contents of 'fieldnames' as a row, but I don't like the idea.

Cheers,

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 think
that we should write headers by default, much like we read them by default.

I believe the implicit header writing is very elegant, and the only
reason that the DictWriter object doesn't write headers is the impedance
mismatch between dicts and CSV.  namedtuples has the field order
information, the impedance mismatch is gone, we should no longer be
hindered.  Implicitly reading but not explicitly writing headers just
seems wrong.

It also seems wrong to require the construction of "header" namedtuple
objects.  It's much less natural than dicts holding identity mappings.

>>> Point._make(Point._fields)
Point(x='x', y='y')

To me, that just looks weird and non-obvious to me.  That Point instance
doesn't really fit in my mind as something that should be a Point.

Rob> I agree that we should not unconditionally write headers, but I
    Rob> think that we should write headers by default, much like we read
    Rob> them by default.

I don't think you should write them by default.  I've worked with lots of
CSV files which have no headers.  I can imagine people wanting to write CSV
files with multiple headers.  It should be optional and explicit.

Skip

More concretely, I don't think this is so onerous:

    names = ["col1", "col2", "color"]
    writer = csv.DictWriter(open("f.csv", "wb"), fieldnames=names, ...)
    writer.writerow(dict(zip(names, names)))
    ...

or

    f = open("f.csv", "rb")
    names = csv.reader(f).next()
    reader = csv.DictReader(f, fieldnames=names, ...)
    ...

Skip

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 files are
sufficiently rare that they shouldn't be created implicitly by
default.  I still don't like the lack of symmetry of supporting
implicit header reads, but not implicit header writes.

On Thu, Feb 26, 2009 at 8:00 PM, Skip Montanaro <report@bugs.python.org> wrote:
>
> Skip Montanaro <skip@pobox.com> added the comment:
>
> More concretely, I don't think this is so onerous:
>
>    names = ["col1", "col2", "color"]
>    writer = csv.DictWriter(open("f.csv", "wb"), fieldnames=names, ...)
>    writer.writerow(dict(zip(names, names)))
>    ...
>
> or
>
>    f = open("f.csv", "rb")
>    names = csv.reader(f).next()
>    reader = csv.DictReader(f, fieldnames=names, ...)
>    ...
>
> Skip
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1818>
> _______________________________________
>

> I don't think you should write them by default.  
> I've worked with lots of CSV files which have no headers. 

My experience has been the same as Skips.

Rob> I still don't like the lack of symmetry of supporting implicit
    Rob> header reads, but not implicit header writes.

A header is nothing more than a row in the CSV file with special
interpretation applied by the user.  There is nothing implicit about it.
If you know the first line is a header, use the recipe I posted.  If not,
supply your own fieldnames and treat the first row as data.

Skip

Added a patch against py3k branch.

in csv.rst removed reference to reader.next() as a public method.

Jervis> in csv.rst removed reference to reader.next() as a public method.

Because?  I've not seen any discussion in this issue or in any other forums
(most certainly not on the csv@python.org mailing list) which would suggest
that csv.reader's next() method should no longer be a public method.

Skip

I don't understand why NamedTupleReader requires the fieldnames array
rather than the namedtuple class itself. If you could pass it the
namedtuple class, users could choose whatever namedtuple subclass with
whatever additional methods or behaviour suits them. It would make
NamedTupleReader more flexible and more useful.

I don't know how NamedTuple objects work, but in many situations you
want the content of the CSV file to drive the output.  I would think
you would use a technique similar to my DictReader example to tell
the NamedTupleReader the fieldnames.  For that you need a fieldnames
argument.

I retract my previous comment.  I don't use the DictReader the way it
operates (fieldnames==None => first row is a header) and forgot about
that behavior.

Jervis> in csv.rst removed reference to reader.next() as a public method.

Skip> Because?  I've not seen any discussion in this issue or in any
Skip> other forums
Skip> (most certainly not on the csv@python.org mailing list) which
would Skip> suggest
Skip> that csv.reader's next() method should no longer be a public method.

I agree, this should be applied separately.

Antoine> I don't understand why NamedTupleReader requires the 
Antoine> fieldnames array
Antoine> rather than the namedtuple class itself. If you could pass it
Antoine> the namedtuple class, users could choose whatever namedtuple 
Antoine> subclass with whatever additional methods or behaviour suits
Antoine> them. It would make NamedTupleReader more flexible and more 
Antoine> useful.

The NamedTupleReader does take the namedtuple class as the fieldnames
argument. It can be a namedtuple, a 'fieldnames' array or None. 
If a namedtuple is used as the fieldnames argument, returned rows are
created using ._make from the this namedtuple. Unless I have read your
requirements incorrectly, this is the behaviour you describe.

Given the confusion, I accept that the documentation needs to be improved. 

The NamedTupleReader and Writer were created to follow as closely as
possible the behaviour (and signature) of the DictReader and DictWriter,
with the exception of using namedtuples instead of dicts.

Ok, I got misled by the documentation ("The contents of *fieldnames* are
passed directly to be used as the namedtuple fieldnames"), and your
implementation is a bit difficult to follow.

Updated version of docs for 2.7 and 3k.