My first request is relatively simple: add a 'yday'
method to datetime.date and datetime.datetime.
Thus I could do:

>>> from datetime import *

>>> t = date.today()
>>> t.yday()
52

# rather than the less readable:
>>> t.timetuple()[7]
52

# or worse:
>>> int(t.strftime('%j'))
52


The second request is to have more alternate
constructors for date or datetime objects. There are
currently:
  * date(year,month,day)
  * date.fromtimestamp(timestamp)
  * date.fromordinal(ordinal)
  * date.today()

I would like to have:
  * date.fromtimetuple(9-item time tuple structure)
  * date.strptime(data_string,format)


As well, it would be nice to change:
  * date(year,month=None,day=None,yday=None)

e.g.,:
>>> date(2006,2,21) == date(2006,yday=52)
True

Here, a date can be formed from a year, month and day
or from just the year and the day of the year,
otherwise I have to convert using:
>>> import time
>>> year = 2006
>>> yday = 52
>>> t = time.strptime(`year`+'-'+`yday`,'%Y-%j')
>>> datetime.date(t.tm_year,t.tm_mon,t.tm_mday)
datetime.date(2006, 2, 21)

If a safer approach is desired (as to not change the
class constructor too much), then please offer an
alternate, say:
  * date.fromyday(year,yday)

or something like that.

Thanks.
+mt

I have completed the following two new features for the datetime module
(the changes are attached as a patch):
a. Added a method yday()
b. Added date.fromyday(year,yday), which returns a date object.
The other features requested are already available.
The tests for these two new features have also been added to
test_datetimemodule.py.
The patch has been only tested on trunk.(Python 2.7)

Some comments:
- since there is already a weekday() method, the new method should be
called yearday() rather than yday()
- ditto for fromyday(): fromyearday() would be better
- Modules/datetimemodule.c should only be indented with tabs, but your
patch indents it with spaces in some places
- the algorithm in date_fromyday() looks suboptimal: if you repeatedly
call days_in_month(), you shouldn't have to call days_before_month() at
the end, you can compute it by yourself

I haven't tested the patch yet.

Marc-André, do you have any take on the principle of this?

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> Some comments:
> - since there is already a weekday() method, the new method should be
> called yearday() rather than yday()
> - ditto for fromyday(): fromyearday() would be better
> - Modules/datetimemodule.c should only be indented with tabs, but your
> patch indents it with spaces in some places
> - the algorithm in date_fromyday() looks suboptimal: if you repeatedly
> call days_in_month(), you shouldn't have to call days_before_month() at
> the end, you can compute it by yourself
> 
> I haven't tested the patch yet.
> 
> Marc-André, do you have any take on the principle of this?

mxDateTime uses attributes for such things, ie. .day_of_week,
.day_of_year, .days_in_month. No idea, why the datetime module
chose to implement access to this static information as method.

I've never had a request for a way to construct a date by
giving the year and day of the year - probably because it's
just too easy to do by hand:

217
>>> Date(2009, 1, 1) + (217 - 1)
<mx.DateTime.DateTime object for '2009-08-05 00:00:00.00' at 2b5320c262f0>

Hmm, looks like there's a bug in roundup's email interface... the code
snippet should have read:

>>> from mx.DateTime import *
>>> today().day_of_year
217
>>> Date(2009, 1, 1) + (217 - 1)
<mx.DateTime.DateTime object for '2009-08-05 00:00:00.00' at 2b5320c262f0>

I think this should be rejected.  The OP's premise was that t.timetuple()[7] was unreadable, but in the modern python, the same can be written as t.timetuple().tm_yday.  The later is only slightly less readable than the proposed t.yday().

For the other half of the proposal, Marc-Andre's mxDate code translates into only slightly more complicated stdlib datetime code:

def date_fromyday(year, yday):
   return date(year, 1, 1) + timedelta(yday - 1)

> I think this should be rejected.  The OP's premise was that
> t.timetuple()[7] was unreadable, but in the modern python, the same
> can be written as t.timetuple().tm_yday.

Could I suggest such example be added to the documentation, though?
The datetime / time jungle is difficult to navigate through, and I think
for most people it is not obvious that the answer to their needs is to
look at one of the attributes of the timetuple() result...

On Thu, May 20, 2010 at 7:27 PM, Antoine Pitrou <report@bugs.python.org> wrote:
>
>> .. The OP's premise was that
>> t.timetuple()[7] was unreadable, but in the modern python, the same
>> can be written as t.timetuple().tm_yday.
>
> Could I suggest such example be added to the documentation, though?

The documentation for timetuple method [1, 2] already contains a
recipe for computing yday which is more efficient than
t.timetuple().tm_yday:

 yday = d.toordinal() - date(d.year, 1, 1).toordinal() + 1

Maybe it can be improved by making it discoverable in searches for yday:

"""
... is equivalent to time.struct_time((d.year, d.month, d.day, d.hour,
d.minute, d.second, d.weekday(), yday, dst)), where yday =
d.toordinal() - date(d.year, 1, 1).toordinal() + 1 is the day number
of the year starting from 1 for January 1st.
"""

[1] http://docs.python.org/py3k/library/datetime.html#datetime.date.timetuple
[2] http://docs.python.org/py3k/library/datetime.html#datetime.datetime.timetuple

Care to suggest a patch?

Attaching a documentation patch.

Committed in r81489.  Thanks!