The following demonstrates the problem:

>>> from datetime import datetime,timedelta
>>> datetime.now().date()+timedelta(hours=1)
datetime.date(2008, 7, 1)

I'd expect the above to either result in a TypeError or (preferably)
datetime.datetime(2008, 7, 1, 1, 0)

This isn't "a bug", since it's functioning as documented and designed.
Read note 1 in the "date Objects" section of the reference manual,
explaining the meaning of "date2 = date1 + timedelta":

"""
date2 is moved forward in time if timedelta.days > 0, or backward if
timedelta.days < 0. Afterward date2 - date1 == timedelta.days.
timedelta.seconds and timedelta.microseconds are ignored. OverflowError
is raised if date2.year would be smaller than MINYEAR or larger than
MAXYEAR.
"""
).

You could call this a feature request instead, but an incompatible
change to documented always-worked-this-way behavior is unlikely to be
accepted.

This may be "as documented" but it's *extremely* counter intuitive and
seems to go against the grain of where python is headed.

(remember that whole struggle to get 3/2 = 1.5 rather 3/2=1? ;-) )

I've changed the "type" to "feature request", what's the best mailing
list to kick off discussion about this?

To be valid, your analogy between dates and numbers suggests that a date
should be convertible to the datetime with the same date, at midnight.
And both objects compare equal, just like 42==42.0

But today this is not the case: it's hard to convert a date into a
datetime, and types cannot be ordered:
>>> datetime.date.today() < datetime.datetime.now()
TypeError: can't compare datetime.datetime to datetime.date

Amaury,

Yes, I agree with you, and that sucks too. I'd suggest opening another
bug for that ;-)

For an allegedly nice, shiny, new and perfect module, datetime sure
seems to have an awful lot lacking...

Chris