>> Andrew explains that in the CSV module, escape characters are not
>> properly removed.
>>
>> Magnus writes:
>>> 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'
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 bu
On 2005 Jan 07, at 14:45, Michael Chermside wrote:
Andrew explains that in the CSV module, escape characters are not
properly removed.
Magnus writes:
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
Andrew explains that in the CSV module, escape characters are not
properly removed.
Magnus writes:
> 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 c
Andrew McNamara <[EMAIL PROTECTED]>:
>
[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:
>
> ["fiel
