Andrew Dalke's space example (was Re: [Csv] csv)

[Dave Cole]

>>>>> "John" == John Machin <sjmachin at lexicon.net> writes:

John> [Dave Cole]
>> Aside from the quote of '\0', I am not sure I follow what you mean.
>> If you set quoting so that it produces ambiguous output that is
>> hardly the fault of the writer.

John> Of course not. What I was getting at was that the ability to
John> write various schemes (some ambiguous, some not) is provided,
John> but it is not possible to read back all unambiguous schemes, and
John> there is little if any support for checking that the data
John> corresponds to the scheme the caller thinks was used to write
John> it, and there are no options to drive what to do on input if the
John> writing scheme was ambiguous.

I must be a bit thick or something...  I have the feeling you are
correct, but I just can't see it.  Can you provide some (simple)
examples and suggest where the code could be improved?

John> [Dave Cole]
>> How much clearer would things be if the validation of dialects were
>> pulled up into the Python?  Being able to see the Python code which
>> raised the exception would be a huge help to the user.

John> How much clearer would things be if the error message said
John> "quotechar must be char, not int"?

Probably only 7 squillion percent.

John> The clarity should arise from the error message, not from its
John> source. I think it a reasonable goal that a developer should
John> have to inspect the callee's source (if available!) only in
John> desperation. The one line of source that is shown in the
John> traceback from Python modules is sometimes not very helpful
John> e.g. the above reasonably helpful error message could have been
John> produced by something like this:

John>    raise NastyError, "%s must be %s, not %s" %
John> (self.attr_name[k], self.attr_type_abbr[k],
John> show_type(input_value))


John> No comments on the possibility of throwing the whole
John> dialect-via-classes idea away???

The dialect should validate when you instantiate it.  This probably
means that we should require a csv.Dialect instance rather than a
class as the parameter to csv.reader() and csv.writer().

>>> class Space(csv.Dialect):
...     delimiter = " "
...     quotechar = False
...     escapechar = False
...     doublequote = False
...     skipinitialspace = False
...     lineterminator = "\n"
...     quoting = csv.QUOTE_NONE
... 
>>> Space()
<__main__.Space instance at 0x401f3dcc>

Is it possible for the csv.Dialect to raise an exception when Space is
instantiated?  I don't know enough about the new style classes.

- Dave

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