datetime and strptime

[Gerrit Holl]

Hi,

it seems the datetime library does not have a .strptime class method.
If I want to create a datetime object from a string, I currently have to do:

datetime.date(*time.strptime(s, "%Y%m%d")[:3])

If the format is more complex (not in the order of a timetuple), it is
even more complicated. In my opinion, it would be better to be able to do:

datetime.date.strptime(s, "%Y%m%d")

Is there a particular reason that this is not possible?
Or is the only reason that it hasn't been implemented?

yours,
Gerrit, who wanted to write a patch until he saw datetime is written in C.

--
233. If a builder build a house for some one, even though he has not
yet completed it; if then the walls seem toppling, the builder must make
the walls solid from his own means.
-- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
http://people.nl.linux.org/~gerrit/
Kom in verzet tegen dit kabinet:
http://www.sp.nl/

[Magnus Lie Hetland]

In article <ma************************************@python.org >, Gerrit
Holl wrote:

Hi,

it seems the datetime library does not have a .strptime class method.

[snip]

Have a look at PEP 321:

http://www.python.org/peps/pep-0321.html

It seems to describe one possible future for the parsing capabilities
of datetime. Under "Generic Input Parsing" the following question is
posed: "Is a strptime() implementation that returns datetime types
sufficient?" No clear answer, though.

--
Magnus Lie Hetland "In this house we obey the laws of
http://hetland.org thermodynamics!" Homer Simpson

[Gerrit Holl]

Magnus Lie Hetland wrote:

In article <ma************************************@python.org >, Gerrit
Holl wrote:

Hi,

it seems the datetime library does not have a .strptime class method.

[snip]

Have a look at PEP 321:

http://www.python.org/peps/pep-0321.html

Ah, yes...
Thanks for the link!

yours,
Gerrit.

--
167. If a man marry a wife and she bear him children: if this wife die
and he then take another wife and she bear him children: if then the
father die, the sons must not partition the estate according to the
mothers, they shall divide the dowries of their mothers only in this way;
the paternal estate they shall divide equally with one another.
-- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
http://people.nl.linux.org/~gerrit/
Kom in verzet tegen dit kabinet:
http://www.sp.nl/

[Robin Munn]

Magnus Lie Hetland <ml*@furu.idi.ntnu.no> wrote:

In article <ma************************************@python.org >, Gerrit
Holl wrote:

Hi,

it seems the datetime library does not have a .strptime class method.

[snip]

Have a look at PEP 321:

http://www.python.org/peps/pep-0321.html

It seems to describe one possible future for the parsing capabilities
of datetime. Under "Generic Input Parsing" the following question is
posed: "Is a strptime() implementation that returns datetime types
sufficient?" No clear answer, though.

I see that PEP targets Python 2.4. If the PEP is accepted and
implemented, I for one would love to see the implementation back-ported
to a 2.3.x patch release. This is something I also (briefly) considered
doing; unfortunately, I can't see myself having any time for this in the
foreseeable future...

--
Robin Munn
rm***@pobox.com

[A.M. Kuchling]

On Wed, 19 Nov 2003 17:09:31 GMT,
Robin Munn <rm***@pobox.com> wrote:

I see that PEP targets Python 2.4. If the PEP is accepted and
implemented, I for one would love to see the implementation back-ported
to a 2.3.x patch release. This is something I also (briefly) considered

The rule for patch releases is "no new features, only bugfixes", so it would
be very difficult to bend the rules for this one method. If the
implementation is just a Python module, though, it would be possible for
someone to package the module for use with 2.3.

--amk

[Anthony Baxter]

Robin Munn <rm***@pobox.com> wrote in message news:<sl******************@rmunnlfs.dyndns.org>...

[ adding datetime.strptime() ]

I see that PEP targets Python 2.4. If the PEP is accepted and
implemented, I for one would love to see the implementation back-ported
to a 2.3.x patch release. This is something I also (briefly) considered
doing; unfortunately, I can't see myself having any time for this in the
foreseeable future...

Absolutely not. Patch releases are for bugfixes only, not new features.
And yes, I'm aware that adding the boolean hackage to 2.2.x broke this
rule, but that was very much the exception rather than the rule.

Based on the feedback from the recent 2.3 releases, one thing that was
appreciated by many people was that there were no new features, or changes
that could break running code. This allows people with production systems
to happily upgrade without fearing for their sanity.