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 current module. Andrew writes back later: > 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. I'm with Magnus on this. No one has 4 year old code using the CSV module. The existing behavior is just simply WRONG. Sure, of course we should try to maintain backward compatibility, but surely SOME cases don't require it, right? Can't we treat this misbehavior as an outright bug? -- Michael Chermside
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4