Minor change to behaviour of csv module
I'm considering a change to the csv module that could potentially break some obscure uses of the module (but CSV files usually quote, rather than escape, so the most common uses aren't effected). Currently, with a non-default escapechar='\\', input like: field one,field \ two,field three Returns: ["field one", "field \\\ntwo", "field three"] In the 2.5 series, I propose changing this to return: ["field one", "field \ntwo", "field three"] Is this reasonable? Is the old behaviour desirable in any way (we could add a switch to enable to new behaviour, but I feel that would only allow the confusion to continue)? BTW, some of my other changes have changed the exceptions raised when bad arguments were passed to the reader and writer factory functions - previously, the exceptions were semi-random, including TypeError, AttributeError and csv.Error - they should now almost always be TypeError (like most other argument passing errors). I can't see this being a problem, but I'm prepared to listen to arguments. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
I'm considering a change to the csv module that could potentially break some obscure uses of the module (but CSV files usually quote, rather than escape, so the most common uses aren't effected).
Currently, with a non-default escapechar='\\', input like:
field one,field \ two,field three
Returns:
["field one", "field \\\ntwo", "field three"]
In the 2.5 series, I propose changing this to return:
["field one", "field \ntwo", "field three"]
Is this reasonable? Is the old behaviour desirable in any way (we could add a switch to enable to new behaviour, but I feel that would only allow the confusion to continue)?
Thinking about this further, I suspect we have to retain the current behaviour, as broken as it is, as the default: it's conceivable that someone somewhere is post-processing the result to remove the backslashes, and if we fix the csv module, we'll break their code. Note that PEP-305 had nothing to say about escaping, nor does the module reference manual. -- Andrew McNamara, Senior Developer, Object Craft http://www.object-craft.com.au/
Andrew McNamara
[snip]
Currently, with a non-default escapechar='\\', input like:
field one,field \ two,field three
Returns:
["field one", "field \\\ntwo", "field three"]
In the 2.5 series, I propose changing this to return:
["field one", "field \ntwo", "field three"]
IMO this is the *only* reasonable behaviour. I don't understand why the escape character should be left in; this is one of the reason why UNIX-style colon-separated values don't work with the current module. If one wanted the first version, one would (I presume) write field one,field \\\ two,field three -- Magnus Lie Hetland Fallen flower I see / Returning to its branch http://hetland.org Ah! a butterfly. [Arakida Moritake]
Andrew> I'm considering a change to the csv module that could Andrew> potentially break some obscure uses of the module (but CSV files Andrew> usually quote, rather than escape, so the most common uses Andrew> aren't effected). I'm with the other respondents. This looks like a bug that should be squashed. Skip
participants (3)
-
Andrew McNamara -
Magnus Lie Hetland -
Skip Montanaro