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

[Brett Cannon]

[Guido van Rossum]

>
> [Tim]
> > I know.  I want to delete the C wrapper too and get rid of
> > HAVE_STRPTIME: full steam ahead, no looking back.  This is pushing
> > back against the growing notion that the way to deal with legacy
> > platform strptime quirks is to keep an option open to recompile
> > Python, to avoid using the portable code.  Since that will be the
> > easiest way out (one person here has already taken it), we'll never
> > get Python's own strptime story straight so long as it's an option.
>
> OK.  Let's get rid of the C wrapper around the C library's strptime().
>
> The C wrapper around _strptime.strptime() stays, of course.  It
> currently has a bit of an inefficiency (what happens when it tries to
> import _strptime is a lot more than I'd like to see happen for each
> call) but that's a somewhat tricky issue that I'd like to put off for
> a little while; I've added a SF bug report as a reminder.  (667770)
>

Anything I can do to help with that?  If it is just a matter of re-coding
it in a certain way just point me in the direction of docs and an example
and I will take care of it.

And to comment on the speed drawback: there is already a partial solution
to this.  ``_strptime`` has the ability to return the regex it creates to
parse the data string and then subsequently have the user pass that in
instead of a format string::

strptime_regex = _strptime.strptime('%c', False) #False triggers it
for line in log_file:
	time_tuple = _strptime.strptime(strptime_regex, line)

That at least eliminates the overhead of having to rediscover the locale
information everytime.  I will add a doc patch with the patch that I am
going to do that adds the default values explaining this feature if no one
has objections (can only think this is an issue if it is decided it would
be better to write the whole thing in C and implementing this feature
would become useless or too much of a pain).

-Brett