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

[Brett Cannon]

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

Now I *really* wish we were ripping ``rexec`` out instead of crippling it.
=)

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

I will see what I can do, but it sounds like this is beyond my experience.

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

Just playing with booleans at the time.  =)  I also thought that it made
sense: False as in it is false that you are going to get any info out of
this.  Although, None also makes sense.  I can change it easily enough.

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

So then I can document it, right?  Or should we just leave this as a
surprise for the more adventurous who read the source?

-Brett