[Csv] Status

[Dave Cole]

>>>>> "Andrew" == Andrew McNamara <andrewm at object-craft.com.au> writes:

>> I'd like not to enumerate all the possible keyword parameters,
>> especially since that list may grow.  How should I write the
>> synopsis?
>> 
>> reader(fileobj [, dialect='excel2000'] [, keyword parameters])
>> 
>> ?

Andrew> Maybe make it "optional keyword parameters"... implied, I
Andrew> know, but...

[I have been franticly trying to reread all of the messages again.
Other work has made me fall behind and lose context.]

Is there any harm in just doing something like this:

  The basic reading interface is::

      reader(fileobj [, **kwargs])

  The dialect keyword argument identifies the CSV dialect which will
  be implemented by the reader.  The dialect corresponds to a set of
  parameters which are set in the low level CSV parsing engine.

  Variants of a dialect can be specified by passing additional keyword
  arguments which serve to override the parameters defined by the
  dialect argument.  The parser parameters are catalogued below.

Andrew> - we could make the dialect parameter accept either a string
Andrew> dialect name or a dialect instance - is this a good idea?

+1 from me.

csv.py::

    class dialect:
        name = None
        quotechar = "'"
        delimiter = ","

    excel2000 = dialect

yourcode.py::

    import csv

    my_dialect = csv.dialect()
    my_dialect.delimiter = '\t'

    # or

    class my_dialect(csv.dialect):
        delimiter = '\t'

    csvreader = csv.reader(file("some.csv"), dialect=my_dialect)

>>  It can pretty easily do both.  Perhaps we should present the pros
>> and cons in the PEP and see what kind of feedback we get.

Andrew> Sometimes you can give people too much choice. We don't have
Andrew> time for an endless discussion. If we don't think we're going
Andrew> to be crucified, we should just pick something that's
Andrew> tasteful. Dave?

If we had to choose one, I would say pass a class or instance rather
than a string.

Andrew> - regarding the dialect list function - this probably should
Andrew> be called list_dialects(), yes?

>>  Where do you see dialect_list()?  Maybe I need to cvs up.  In any
>> case, I like list_dialects() better.

Andrew> Ah - I mean "dialect list function" in the generic sense - we
Andrew> need one, and I was proposing to call it list_dialects, or
Andrew> maybe that should be listdialects to be like listdir... nah,
Andrew> looks ugly.

+1 list_dialects()

Andrew> - should we call the delimiter parameter "field_sep" instead
Andrew> (I notice you haven't used underscores in the parameter names
Andrew> - is this deliberate)?

>>  I don't have a big preference one way or the other.  I've been
>> calling it "delimiter" though.

+1 delimiter (I think :-)

- Dave

-- 
http://www.object-craft.com.au