[Python-Dev] Re-introduce caching for _strptime.py for 2.3.1?
Brett C.
bac at OCF.Berkeley.EDU
Tue Aug 5 20:59:43 EDT 2003
More information about the Python-Dev mailing list
Tue Aug 5 20:59:43 EDT 2003
- Previous message: [Python-Dev] Re-introduce caching for _strptime.py for 2.3.1?
- Next message: [Python-Dev] IDLE NEWS and Version
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tim Peters wrote: > [Brett, on strptime changes] > >>... >>My question is whether I should backport any of this. > > > I'm with Raymond: yes. Ripping out the cache for 2.3 final was a > time-pressure bugfix that wouldn't have been needed had you had another day > to repair it correctly. I'm not so keen on adding complications beyond that > for "thread safety", though, as locale is inherently thread-insane in the > absence of a user-implemented locking protocol (but since most programs will > at worst change locale once at the start, worry about threads is mostly > wasted regardless). > OK, having two people whose opinions I trust say I should add it back in I will. What I will do is diff back to the last version that had caching, re-implement the fix for the bug (it was like four lines of code that are brain-dead simple) and then apply that to the 2.3.x branch. I won't make any changes for the sake of thread-safety to LocaleTime and such. There is a possibility of some weird race condition since I cache an instance of TimeRE and a dict of compiled regexes that is dependent on TimeRE, but I am having a hard time coming up with an issue outside of locale funkiness so I won't worry about it with 2.3.x (dealt with in 2.4 as a safety precaution). -Brett
- Previous message: [Python-Dev] Re-introduce caching for _strptime.py for 2.3.1?
- Next message: [Python-Dev] IDLE NEWS and Version
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list