[Python-ideas] Date/time literals

[Marcos Bonci]

Hey, thanks for your response, Chris!

Reading the rest of your post, it sounds like you're unaware of the

fairly nice API of the `datetime` std lib module:


Yes, you're (partially) right. I did know it existed, but I guess I forgot
about it and got used to the wrong modules. This one does seem
to have most (if not all) of what I was talking about, and does look
like "the obvious way".

But there are some limitations I don't understand the reason for.
Why aren't negative years allowed? (That ISO regulation I mentioned
earlier "says it's ok".) And why does `toordinal` return an int (ignoring
the "time" part of a `datetime`)?

And I still fail to see any disadvantage in having date and time
literals (probably as shortcuts for the already existing datetime types,
or a future version of them).

But maybe it's all just me putting my nose where it doesn't belong :)

-- Marcos --


On 29 May 2010 22:49, Chris Rebert <pyideas at rebertia.com> wrote:

> On Sat, May 29, 2010 at 6:05 PM, Marcos Bonci <marcos.bonci at gmail.com>
> wrote:
> > Hi!
> > I've been working a lot with date/time variables lately, and maybe it's
> just
> > me, and
> > maybe I just don't get it yet, but it sure doesn't feel like there's
> > one-and-only-one
> > elegant, obvious way to work with them. Feels like working with strings
> in
> > C.
>
> Reading the rest of your post, it sounds like you're unaware of the
> fairly nice API of the `datetime` std lib module:
> http://docs.python.org/library/datetime.html
>
> IMO, it's pretty nice to work with; although it is annoying that some
> operations can only be done using the more primitive `time` or
> `calendar` modules. Patches are probably welcome; perhaps I should
> consider trying to write one.
>
> > So I was thinking, have date and time literals ever been seriously
> > discussed anywhere
> > in these discussion lists? (If so, I apologize in advance for reviving
> this
> > subject.)
> > Is there any chance we could ever see date/time literals in Python?
>
> Well, the datetime module does appear to already be written in C, so
> that'd be one less hurdle.
> I wasn't able to find a prior post on the exact subject; perhaps
> someone else will.
>
> > Perhaps as a top-level
> > abstraction itself, or as a subclass of numbers.Number, or even as common
> > float or int
> > (by adding attributes regarding specific properties of a number's
> date/time
> > interpretation,
> > e.g. "<2010-12-31>.incr_month(2) == <2011-02-28>" -- just an example
> though,
> > i don't really
> > think this exact method would be practical).
>
> The `datetime` module already provides nice and more typesafe
> abstractions; purposefully conflating date/times with plain numbers is
> not a good idea, imo.
>
> <snip>
> > Very often the "time elapsed" value
> > is what we really
> > want (or at least the absolute difference between two values, which is of
> > course easier to find
> > in this form), and besides being more compact and flexible, no
> functionality
> > is lost.
>
> datetime.timedelta:
> http://docs.python.org/library/datetime.html#timedelta-objects
>
> > I guess the most controversial point here would be the meaning of
> arithmetic
> > operations
> > between dates (or the very validity of such operations).
>
> Already defined and accepted as valid:
> datetime.date, "Supported operations"
> http://docs.python.org/library/datetime.html#date-objects
>
> <snip>
> > So, what do you guys think? I'd love to hear others' opinions, even if
> it's
> > just for me
> > to understand what I got wrong and see the obvious way that's already
> there
>
> I think the classes in the `datetime` module are the nice "missing"
> API that you're looking for, and that there's not enough of a gain to
> justify complicating the language by adding literals for them and
> making them built-in types.
>
> Cheers,
> Chris
> --
> http://blog.rebertia.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100530/a1f5493c/attachment.html>