➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients kalaxy, lukasz.langa, maciej.szulik, mjohnson, python-dev, r.david.murray, serhiy.storchaka, terry.reedy
Date 2017-09-30.03:05:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1506740760.26.0.213398074469.issue15927@psf.upfronthosting.co.za>
In-reply-to
Content 
This issue was 'reopened' by #31590.

I can understand inconsistency as a 'design bug', but design bugs are not code bugs, and fixing a design bugs is an enhancement issue, not a behavior issue.

It is not clear to me why, with the specified dialect,  "writer.writerow(['one\nelement'])" is correct in writing 'one\\\nelement\n'.  The doc for Dialect.excapechar says "A one-character string used by the writer to escape the delimiter if quoting is set to QUOTE_NONE and the quotechar if doublequote is False."  Yes, quoting is set to QUOTE_NONE, but \n is the lineterminator, not the delimiter (or the quotechar).  It looks to me that escaping the lineterminator might be a bug.

In any case, 'one\nelement' and 'one\\\nelement' are each 2 physical lines.  I don't see anything in the doc about csv.reader joining physical lines into 'logical' lines the way that compile() does.
History
Date User Action Args
2017-09-30 03:06:00terry.reedysetrecipients: + terry.reedy, r.david.murray, lukasz.langa, python-dev, serhiy.storchaka, maciej.szulik, kalaxy, mjohnson
2017-09-30 03:06:00terry.reedysetmessageid: <1506740760.26.0.213398074469.issue15927@psf.upfronthosting.co.za>
2017-09-30 03:06:00terry.reedylinkissue15927 messages
2017-09-30 03:05:59terry.reedycreate