-
-
Notifications
You must be signed in to change notification settings - Fork 30.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
csv module: Add return value to DictWriter.writeheader #71684
Comments
Currently, DictWriter.writeheader() is defined like: def writeheader(self):
header = dict(zip(self.fieldnames, self.fieldnames))
self.writerow(header) It would be useful to have it return the value of writerow(): def writeheader(self):
header = dict(zip(self.fieldnames, self.fieldnames))
return self.writerow(header) This would useful because:
|
This seems like a reasonable request, but could only be done in 3.6 as it would be a new feature. |
It doesn't seem right to me. The writer should be blocking: write *all* data, don't use partial write. Supporting partial write (non-blocking files) requires more changes, and it isn't worth it. Here the problem is that the function doesn't support partial write. Each time, it tries to write the full content. What is your use case? |
It isn't documented that writer.writeline returns anything, but what it actually returns is whatever the write method of the underlying file object returns. Obviously (given the linked example), this fact is being used. There is value in consistency, so I think we should make this change. |
It is a bit irritating to have this small API inconsistency, but I'm a little wary of propagating this undocumented and untested behavior especially given Victor's concern about whether it makes any sense in this context. Skip, what do you think? |
It doesn't make sense when the return value is that provided by io.write. It does make sense in the context of the linked example (a psuedo-file object). However, it *is* an undocumented API, even if people are using it. |
Oh. I missed the django recipe to implement "streaming csv". It uses an This recipe looks like an abuse of the API, but I understand that there is Maybe we should extend the API? |
By the way, there is an open ticket about changing the recipe in Django documentation: https://code.djangoproject.com/ticket/26040 |
I agree writeheader() should have returned the value of writerow(), but have no opinion on the more esoteric stuff you're discussing. I think you could argue that adding the "return" would be a bug fix. Personally, I long ago got in the habit of using the writerow(dict(zip(fh, fh))) idiom, didn't catch on at the time that writeheader() was even available in 2.7, and still just use the idiom most of the time. It's a one-liner. The OP could easily use that in contexts where writeheader() doesn't do the right thing. |
@berker.peksag: Good catch, thank you. In my code base I'm using a slightly different implementation which does use an iterator, so I didn't even catch that the default django example was incorrect. @skip.montanaro: That is exactly the one-liner I'm currently using. Thank you for documenting it here in case anyone else is looking for the same. |
I'm now ok to add the return, but only in Python 3.6. It would be a minor new "feature". |
Hi, I have added the "return" to the writeheader method. I ran the tests for the csv library (./python -m test -v test_csv) and got no errors (Ran 101 tests in 0.322s; 1 test OK.). Kindly review the patch. |
Also, I noticed in the documentation for I can make another thread if required, if you feel both the changes can't be accommodated in the same issue. |
Thanks! The patch lacks a test case (you can add it into Lib/test/test_csv.py) and a versionchanged notice in documentation (see http://cpython-devguide.readthedocs.io/en/latest/documenting.html#paragraph-level-markup for details.) |
Also, a change in behavior has to be very carefully considered, even On Mon, Sep 5, 2016 at 7:31 AM, Berker Peksag <report@bugs.python.org> wrote:
|
Thank you Berker & Skip for your review & additional inputs. Will keep these in mind while making a patch next time :) |
I would like to drive this to conclusion since it appears this issue has not had any real activity in a while. First thing that needs to be determined is whether this enhancement is still desirable. Who can answer this? |
Michael, there is a up-to-date PR that's waiting for approval. |
Ah ha, so there is. I'm glad this one will get closed out. Sorry for noob mistake. |
I think this is ready to go. I added a comment to PR12306. As I am no longer a committer, I'm not sure what the next step is. |
I merged PR 12306. Thanks Ashish Nitin Patil for the initial patch, thanks Rémi Lapeyre to converting it to a PR, thanks Logan for the initial bug report ;-) Sadly, this change is a new feature and so cannot be backported to 2.7 or 3.7. The workaround is override the method: def writeheader(self):
header = dict(zip(self.fieldnames, self.fieldnames))
return self.writerow(header) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: