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.

classification
Title: Additional implementation alternative to DictReader
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.7, Python 3.6, Python 2.7
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: foxfluff, methane, r.david.murray, rhettinger, serhiy.storchaka
Priority: normal Keywords:

Created on 2017-02-21 20:27 by foxfluff, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 223 closed foxfluff, 2017-02-21 20:43
Messages (8)
msg288318 - (view) Author: foxfluff (foxfluff) * Date: 2017-02-21 20:27
As discussed in the following:
https://bugs.python.org/issue17537
https://mail.python.org/pipermail/python-ideas/2013-January/018844.html

DictReader has a feature that will destroy data without warning if fieldnames had duplicate values (manual or automatic entries)

Proposing renaming and re-implementation of DictReader class to instead return enumerate style output with a child class of DictReader to specifically return a dict object.
msg288331 - (view) Author: Inada Naoki (methane) * (Python committer) Date: 2017-02-22 05:08
I don't feel TableReader is really useful.

Would you show some realistic example when TableReader is better than
normal csv.Reader?
msg288362 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-02-22 14:56
Inada: I believe the goal is to be able to handle CSV files that have columns with duplicate names.  However, in that case one could just use the regular reader class.  The only advantage TableReader gives over the regular reader that I can see is that it automatically reads the header line and sets fieldnames.  I'm not sure that is enough motivation for introducing a whole new class.

It also doesn't address the issue the OP mentions, that columns are overwritten silently by DictReader.  However, that is a characteristic of dicts in Python in general, so I'm not sure I even see that as a bug.

Overall, I'm -1 on this proposal.
msg288365 - (view) Author: foxfluff (foxfluff) * Date: 2017-02-22 15:20
David:
You are correct that the goal is to handle CSVs with duplicate headers, and that the main intention is to have some of the behavior of DictReader without the destruction of data (such as the auto population of field names as you stated).

It is not the intention of this to change the behavior of DictReader, as stated in issue 17537. It is instead covering a problem that was discussed later in the thread and would offer an alternative solution with non destructive behavior to DictReader while maintaining backwards compatibility.
msg288367 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-02-22 15:37
My opinion stated in that issue is still the same: I don't think this is a bug.  I don't think automatic handling of fieldnames when no other dictionary features are retained is worth the complication to the API.  So I'm still -1.  We'll see what other people think.
msg288368 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-22 16:05
I'm with Inada and David. This use case looks very specific. If you need to handle a CSV file with duplicated header, you can use the regular reader or implement your own specialised reader.
msg288369 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-02-22 16:12
Or use DictReader with an explicit fieldnames argument.
msg288393 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-02-23 00:06
I concur with Serhiy, David, and Inada

Marking this as closed.
History
Date User Action Args
2022-04-11 14:58:43adminsetgithub: 73800
2017-02-23 00:06:36rhettingersetstatus: open -> closed

nosy: + rhettinger
messages: + msg288393

resolution: rejected
stage: resolved
2017-02-22 16:12:52serhiy.storchakasetmessages: + msg288369
2017-02-22 16:05:17serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg288368
2017-02-22 15:37:55r.david.murraysetmessages: + msg288367
2017-02-22 15:20:05foxfluffsetmessages: + msg288365
2017-02-22 14:56:45r.david.murraysetnosy: + r.david.murray
messages: + msg288362
2017-02-22 05:08:42methanesetnosy: + methane
messages: + msg288331
2017-02-21 20:43:40foxfluffsetpull_requests: + pull_request187
2017-02-21 20:27:20foxfluffcreate