R. David Murray rdmur...@bitdance.com added the comment:
Drat, missed this one when I was reviewing my issues for feature requests
because I didn't change the type :(
--
versions: +Python 3.3 -Python 3.2
___
Python tracker rep...@bugs.python.org
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: -BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6302
___
___
Barry A. Warsaw ba...@python.org added the comment:
In email6, can we at least make tuple returning methods return namedtuples
instead?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6302
Barry A. Warsaw ba...@python.org added the comment:
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
Antoine Pitrou pit...@free.fr added the comment:
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
Barry A. Warsaw ba...@python.org added the comment:
The point of a new method is to return the header as a human-readable
string, rather than a list of tuples. It has added value besides
leaving the old method alone ;)
+1 then! :)
--
___
Python
Antoine Pitrou pit...@free.fr added the comment:
I think nttplib's use case can be satisfied via the issue 4661 patch
coupled with the decode_header bytes-recovery enhancement.
I don't really understand how that could.
nntplib needs to decode (in the decode_header sense) headers containing
R. David Murray rdmur...@bitdance.com added the comment:
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
R. David Murray rdmur...@bitdance.com added the comment:
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,
Changes by R. David Murray rdmur...@bitdance.com:
--
versions: -Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6302
___
___
Mark Lawrence breamore...@yahoo.co.uk added the comment:
Anyone got any comments to make on this? Should 2.7 also be included?
--
nosy: +BreamoreBoy
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6302
R. David Murray rdmur...@bitdance.com added the comment:
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.
--
assignee: - r.david.murray
New submission from R. David Murray rdmur...@bitdance.com:
decode_header only accepts str as input. If the input contains no
encoded words, the output is str (ie: the input string) and None. If it
does contain encoded words, the output is pairs of bytes plus str
charset identifiers (or None).
13 matches
Mail list logo