[Python-Dev] dateutil
Tim Peters
tim.one at comcast.net
Sun Mar 14 23:12:36 EST 2004
[Gustavo Niemeyer]
> Tim, first, thank you very much for your careful review of the
> relativedelta documentation. It looks like most of these issues
> are result of the documentation being written by someone which
> already knew how things work out, and was deeply involved in the
> development.
Probably, yes.
> I'll try to answer your doubts here, and later I'll review the
> documentation again trying to explain these issues in a better,
> non-ambiguous way.
There's no need to reply to me at all <wink>. It does suggest that if you
want to fold it into the core, a PEP is really in order. The usual way
things go is that you get no feedback at all until *someone* asks questions
in public. That gets other people thinking about it too, and then the
floodgates open. For example, I see Greg Ewing already took the bait, and
has his own set of design questions. While I'm sure the bulk of the
questions I asked have clear and non-controversial answers, some of the
decisions are debatable.
[Greg Ewing]
> I think the OP's question was what happens if you do
>
> for i in range(12):
> d += relativedelta(months=+1)
Gustavo partially explained that via a different example:
> >>> rd = relativedelta(months=+1)
> >>> d = date(2000,2,29)
> >>> for i in range(12):
> ... d += rd
> >>> d
> datetime.date(2001, 2, 28)
I assume that if d had been date(2000, 1, 31) instead, we would have wound
up with date(2001, 1, 29), so that adding relativedelta(months=+12) is the
same as adding relativedelta(years=+1), but neither is necessarily the same
as adding relativedelta(months=+1) 12 times. That's defensible, it's just
not obvious either way.
> So a relativedelta can affect things in a way that's not
> relative at all? That sounds *very* confusing.
>
> Wouldn't it be better if relativedelta confined itself to
> relative things only, and provide some other way of
> absolutely setting fields of a date?
I'm sure this part was inherited from mxDateTime. I find it confusing to
slam so much mixed functionality into a single type. The Python datetime
types support .replace() methods already for replacing fields with absolute
values, although they complain if an out-of-range replacement is attempted;
e.g.,
>>> from datetime import *
>>> now = date.today()
>>> now
datetime.date(2004, 3, 14)
>>> now.replace(month=2, day=29)
datetime.date(2004, 2, 29)
>>> now.replace(month=2, day=30)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: day is out of range for month
>>>
This makes operations like "move to the end of the current month"
non-trivial (not *hard*, just non-trivial). I'm not sure they're trivial in
Gustavo's scheme either, though. Java supports distinct notions of "set",
"add" and "roll" to cater to different use cases, and a discussion of that
would be great to see in a PEP:
http://java.sun.com/j2se/1.3/docs/api/java/util/Calendar.html
I'll confess in advance that I can't make sense of them either <wink>.
More information about the Python-Dev
mailing list