Did you read "Unfortunately, delimiter is represented by a character in C." in one of the answers? If so, this should be rejected. For the posted problem, I added the following. >>> list(s[1:-1] for s in '"1234"|
> I do not see the need to cater to something as foolish and rare as using a multichar delimiter that is also within fields. I need to generate tables for Google Code wikis.
You did not explain why it is *impossible* for you to use any of the other solutions. In any case, I looked at the C code. It defines delimiter (as well as quotechar and escapechar) as a single unicode char. This is different from Python which does not have a char type but uses strings (arrays) of length one as a substitute. Redefining delimiter as an array of unicode chars, as you propose, would complicate the code. It will take a much stronger case than one person's 'It would be nice' to motivate someone with the needed C skills to do the revision. It would as least slightly slow down all single char uses. It would be easier and more useful, in some ways, to write a Python csv version. You might look elsewhere for an enhanced csv reader that handles multi-char delimiters. Searching just pypi for 'csv' returns perhaps 50 hits. If you really want to pursue this for the stdlib, follow my suggestion of posting to python-ideas and reference this issue.
I have posted on python-ideas. On 9 March 2013 03:14, Terry J. Reedy <report@bugs.python.org> wrote: > > Terry J. Reedy added the comment: > > You did not explain why it is *impossible* for you to use any of the other > solutions. In any case, I looked at the C code. It defines delimiter (as > well as quotechar and escapechar) as a single unicode char. This is > different from Python which does not have a char type but uses strings > (arrays) of length one as a substitute. Redefining delimiter as an array of > unicode chars, as you propose, would complicate the code. It will take a > much stronger case than one person's 'It would be nice' to motivate someone > with the needed C skills to do the revision. It would as least slightly > slow down all single char uses. It would be easier and more useful, in some > ways, to write a Python csv version. > > You might look elsewhere for an enhanced csv reader that handles > multi-char delimiters. Searching just pypi for 'csv' returns perhaps 50 > hits. If you really want to pursue this for the stdlib, follow my > suggestion of posting to python-ideas and reference this issue. > > ---------- > nosy: +skip.montanaro > resolution: -> rejected > stage: test needed -> committed/rejected > status: open -> closed > > _______________________________________ > Python tracker <report@bugs.python.org> > <http://bugs.python.org/issue15158> > _______________________________________ >
History
Date
User
Action
Args
2022-04-11 14:57:31
admin
set
github: 59363
2013-03-09 03:31:36
Ramchandra Apte
set
messages: +
2013-03-08 21:44:32
terry.reedy
set
status: open -> closednosy: + skip.montanaromessages: + resolution: rejectedstage: test needed -> resolved
2012-10-04 14:02:09
Ramchandra Apte
set
messages: +
2012-07-01 00:45:03
terry.reedy
set
versions: - Python 3.3nosy: + terry.reedymessages: + stage: test needed
