[Python-Dev] Broken strptime in Python 2.3a1 & CVS

[Brett Cannon]

[Paul Moore]

> Brett Cannon <bac@OCF.Berkeley.EDU> writes:
>
> > 	2) Define our own standard on return values -- This would require
> > editing timemodule.c to make sure any C version that gets used conforms to
> > what we specify.  The other option is to just remove the C version and use
> > the Python version exclusively; speed and backwards-compatibility be
> > damned, although the docs leave such a big hole open for what ``strptime``
> > will do that it would still conform to the docs.  =)
>
> I've not been following this much, and I come from a platform
> (Windows) with no C version of strptime, so I'm both grateful for the
> new version, and unconcerned about compatibility :-) However, I think
> there's a slightly less aggressive compromise. Would it be possible
> (or useful) to specify and document the behaviour of the Python
> version (essentially, "define our own standard"), but rather than jump
> through hoops to force C versions into conformance, just punt and say
> that C versions, when used, may differ in their handling of
> unspecified input?
>

I don't know how much help it would be stating what the Python version
does explicitly and then saying we have no clue what the C version might
do *and* you don't get to control which version ``time`` uses.  You might
as well stick with what the docs say as-is and say we don't guarantee what
you will get.

> This probably only makes sense as an option if:
>
> a) The Python user can be expected to *know* whether they have the C
>    version or the Python version, and

Would ``time.strptime == _strptime.strptime`` actually work?  Otherwise
there is no way to know without setting some module flag.

> b) People writing code for portability have a way of defending against
>    the differences (or they write to the lowest common denominator of
>    making no assumptions...)
>

Well, we could tell people that they could import ``_strptime`` directly
if they want to use the Python version.  I mean this whole issue is solved
if people passed their time tuples through I brain-dead simple function
that unpacked the tuple and tested that values within the valid range if
they weren't gave them values that made sense.  But then the question
becomes do we want to do this for the user in the library or should we let
them do it themselves.

-Brett