Repository navigation
email.utils.{parsedate,parsedate_tz} should have better return types #54073
Description
| BPO | 9864 |
|---|---|
| Nosy | @warsaw, @abalkin, @pitrou, @merwok, @bitdancer |
| Dependencies | |
| Superseder | |
| Files |
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:
assignee = 'https://github.com/bitdancer'
closed_at = <Date 2012-05-26.03:37:38.459>
created_at = <Date 2010-09-15.19:05:23.195>
labels = ['type-feature', 'library']
title = 'email.utils.{parsedate,parsedate_tz} should have better return types'
updated_at = <Date 2012-05-26.03:37:38.458>
user = 'https://github.com/pitrou'bugs.python.org fields:
activity = <Date 2012-05-26.03:37:38.458>
actor = 'r.david.murray'
assignee = 'r.david.murray'
closed = True
closed_date = <Date 2012-05-26.03:37:38.459>
closer = 'r.david.murray'
components = ['Library (Lib)']
creation = <Date 2010-09-15.19:05:23.195>
creator = 'pitrou'
dependencies = ['9909']
files = ['18942', '19040']
hgrepos = []
issue_num = 9864
keywords = ['patch']
message_count = 15.0
messages = ['116473', '116474', '116475', '117026', '117027', '117056', '117060', '117063', '117124', '117162', '117165', '117328', '117496', '117555', '161645']
nosy_count = 6.0
nosy_names = ['barry', 'belopolsky', 'pitrou', 'eric.araujo', 'r.david.murray', 'jfinkels']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = 'resolved'
status = 'closed'
superseder = '665194'
type = 'enhancement'
url = 'https://bugs.python.org/issue9864'
versions = ['Python 3.3']
Activity
pitrou commentedon Sep 15, 2010
They both return raw tuples, which are not very intuitive to interpret:
>>> email.utils.parsedate_tz("Wed, 15 Sep 2010 09:53:50 -0700 (PDT)") (2010, 9, 15, 9, 53, 50, 0, 1, -1, -25200)It would be much better if they returned some kind of namedtuple, which would preserve backwards compatibility but with much better readability and usability.
Note that parsedate() could also return the existing time.struct_time type (which is compatible with a 9-tuple):
http://docs.python.org/library/time.html#time.struct_time
warsaw commentedon Sep 15, 2010
+1
pitrou commentedon Sep 15, 2010
By the way, while as mentioned in the docs “indexes 6, 7, and 8 of the result tuple are not usable”, perhaps it would be time to fix it? (at least for 6 and 7, aka. wday and yday)
jfinkels commentedon Sep 21, 2010
If the changes I propose in bpo-9909 are implemented (briefly: a calendar.dayofyear() function), the following patch (with documentation and tests) should fill in the missing fields in the returned tuple.
Note that the email._parseaddr module now depends on the calendar module.
jfinkels commentedon Sep 21, 2010
I was not clear: the patch I provided REQUIRES the function I provided in bpo-9909. But I don't know how to change the "Dependencies" field in Roundup.
abalkin commentedon Sep 21, 2010
I've added bpo-9909 as a dependency, but IMO it is less likely to be accepted than this feature request.
On this issue, I would much rather see email package to start using datetime objects to represent time rather than named or unnamed tuples.
pitrou commentedon Sep 21, 2010
I agree on the principle, but I don't know if it's acceptable with regards to compatibility. It's up to David and Barry to decide.
warsaw commentedon Sep 21, 2010
It does make sense, and email6 is like Python 3 in the sense that backward compatibility is not a priority.
bitdancer commentedon Sep 22, 2010
Yes, email6 should make use of datetime objects. For email5 Antoine's proposal is better, but the question is will it happen before 3.2 beta :)
bitdancer commentedon Sep 23, 2010
I'm assigning this to myself because I'm assigned on all email issues, but that shouldn't prevent someone from working on a patch implementing Antoine's suggestion.
jfinkels commentedon Sep 23, 2010
Where does "email6" live?
bitdancer commentedon Sep 24, 2010
http://launchpad.net/python-email6
jfinkels commentedon Sep 28, 2010
Here's a patch for the python-email6 branch.
It seemed to make sense to remove parsedate_tz() and mktime_tz() here, since the parsedate() function now returns a datetime object, including timezone information (if it was parsed from the input string).
Also required updating several tests to work with the new return type, and removing a test that checked if the returned value of parsedate() (a time tuple) was "acceptable" for use with functions from the time module.
bitdancer commentedon Sep 28, 2010
Thanks, Jeffrey. I've applied your patch (with minor doc tweaks) to the email6 branch.
bitdancer commentedon May 26, 2012
We ended up deciding to keep backward compatibility and add datetime support as a new API. All of these changes are now checked in to default. (See bpo-665194, as well as bpo-12586.)