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

[John Machin]

On 16 Feb 2003 21:59:21 +1100, Dave Cole <djc at object-craft.com.au> wrote:

[John Machin]
>> There are various problems brought out by Andrew's example; see
>> attached file dalke.py

>> (3) The "quoting" argument is honoured only by writers, not by
>> readers -- i.e. in general you can't reliably read back a file that
>> you've created and in particular to read Andrew D's files you need
>> to set quotechar to some char that you hope is not in the input --
>> maybe '\0'.

[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.

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

[John Machin]
>> (4) Maybe the whole dialect thing is a bit too baroque and Byzantine
>> -- see example 5 in dalke.py. The **dict_of_arguments gadget offers
>> the "don't need to type long list of arguments" advantage claimed
>> for dialect classes, and you get the same obscure error message if
>> you stuff up the type of an argument (see example 6) -- all of this
>> without writing all that register/validate/etc code.
>
[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.

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

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

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


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


--