RetroSearch Browse

Sun Mar 14 23:12:36 EST 2004 · http://mail.python.org/pipermail/python-dev/2004-March/043121.html

[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>.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2004-March/043121.html below:

[Python-Dev] dateutil