[Python-Dev] Broken strptime in Python 2.3a1 & CVS (original) (raw)

Brett Cannon bac@OCF.Berkeley.EDU
Tue, 14 Jan 2003 13:41:45 -0800 (PST)

[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:: > > strptimeregex = 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 logfile: > timetuple = strptime.strptime(strptimeregex, 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