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
Add decode_header_as_string method to email.utils #50551
Comments
decode_header only accepts str as input. If the input contains no I think decode_header should take bytes as input, and output (bytes. In any case, the documentation is wrong since it says it returns [(b'p\xf6stal', 'iso-8859-1')] |
Anyone got any comments to make on this? Should 2.7 also be included? |
No, this is a 3.x only problem. And my main comment is that decode_headers ought to go away as an API :) But I'll try to fix the inconsistent data types problem before 3.2. |
Here is a patch that makes the output consistently (bytes, string) pairs. This is definitely a potential backward compatibility issue, but in general code which compensates for the old behavior should work fine with the new behavior, since it was always possible to get a (bytes, None) tuple back as a result, so most code should be handling that case correctly already. IMO this change is nevertheless worthwhile; especially since if the patch in bpo-4661 is accepted decode_header can be enhanced so that it will provide a way to obtain the bytes version of a header containing (RFC invalid) non-ASCII bytes. Note that this breaks one of the tests in nttplib, so backward compatibility really is an issue, unfortunately. I think nttplib's use case can be satisfied via the bpo-4661 patch coupled with the decode_header bytes-recovery enhancement. |
I don't really understand how that could. Since the decode_header() API is so silly to begin with, I'd suggest providing another higher-level API instead. One which takes an str and returns another str (not bytes!) instead of that list of tuples. If you really want to "fix" the current decode_header(), I'd recommend adding an optional "encoding" parameter so that nntplib can give utf-8 instead of ascii. nntplib and other consumers will still have to decode back in order to get an str, which makes the whole encoding thing a bit useless. Oh, and instead of None, it would be nicer to give the actual encoding (e.g. "ascii"). It's no fun trying to guess. |
Here is a proposal for decode_header_as_string(). |
Yes, that was a late night post and as I was falling asleep I realized that I was wrong. Certainly decode_header_as_string is a function most people using the email package will want and will re-implement in one form or another, so I think it is a good idea to add it. I will take a look at the patch later. And with such a function added we can leave decode_header alone for backward compatibility. |
In email6, can we at least make tuple returning methods return namedtuples instead? |
I agree that it makes sense to have consistent types in the output. As for whether to add a new method or fix the existing one, I'm a bit torn, but I'd probably opt for fixing the existing function rather than adding a new one, just because I think there are few Python 3 applications out there that are counting on the old behavior. (I could be wrong though ;). |
The point of a new method is to return the header as a human-readable |
+1 then! :) |
Drat, missed this one when I was reviewing my issues for feature requests because I didn't change the type :( |
All of this is going to be fixed a different (better :) way in an upcoming patch that will add a new header parsing/folding policy to the email package. For the record, the way to spell the "decode a header and return a string" function using the existing API is: str(make_header(decode_header(<someheader>))) |
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: