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

[Guido van Rossum]

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

The issues are really subtle.  E.g. you can't just store the python
strptime function in a global, because of multiple independent
interpreters and reload().  You can't peek in sys.modules because of
rexec.py.

If you still want to look into this, be my guest.

> 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

Why False and not None?

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

Yeah, but this means people have to change their code.  OK, I think
for speed hacks that's acceptable.

--Guido van Rossum (home page: http://www.python.org/~guido/)