Request for a change in the csv module.

[Diez B. Roggisch]

Paulo da Silva wrote:

> Diez B. Roggisch escreveu:
>> Paulo da Silva schrieb:
> ...
> 
>>> That works but it is a pain to use.
>> 
>> Why? I think it's straightforward.
> 
> That is not the point. The problem is to have things generalized.
> I have some general purpose tables whose fields format I don't know
> in advance.
> Internally the numeric values are independent of localization.
> Having a table, I don't like the idea of preformating things
> before sending them to the csv for exportation. A little more
> of programming and there will be no need for csv at all :-)
> ...

This is simply _not_ true. The details of a proper CSV format are difficult
to get right, which is precisely why the module is there.

>> The same is essentially true for dates as well, btw. How do you want to
>> deal with them?
> 
> This is a pertinent question I didn't think of. May be csv should handle
> data conversions using 'locale'.
> It is already automatically converting numbers to text
> anyway, but unconditionally using the '.'.
> As for the dates the dialect could include a format like YYYY-MM-DD
> hh:mm:ss. Dates are not always 'locale' only. In pt_PT we use
> YYYY-MM-DD or YY-MM-DD and sometimes DD-MM-YYYY.
> One must remember that csv is not part of the language. So, to have
> some kind of universality, it must use the specs (in dialect) for
> formatting and 'locale' for data conversions.

I'm not too convinced. It's so darn easy to convert the values to what one
really needs for the actual use-case. Even for your generic case - all you
need is type-based formatting dispatch.

But if you add that complexity to the writers of the csv-module, you'll end
up with a nasty configuration mechanism for special casing individual
columns, or otherwise the next user comes and says "well, I need to format
dates differently just for this case, how to do so in the csv-module". As
your own example shows. 

The purpose of the module is solely to assist in creating properly formatted
csv content in the sense that it is readable and parsable and results in
strings for column values. Not more, not less (and you seem to
underestimate that task, btw.)

That it does convert non-string-values to strings when writing could be seen
as convenience, or actual bug as it might cause troubles as you perceived
them - but the solution would clearly be to get rid of this functionality,
not enhance it.

Diez