- Removed caching of TimeRE (and thus LocaleTime) in _strptime.py to
- fix a locale related bug in the test suite. Although another patch
- was needed to actually fix the problem, the cache code was not
- restored.
FWIW, I would feel safer if the cache code were restored. That code has been around for while and the one defect is known. In contrast, the "ripping it out" touched a lot of code and has not been thoroughly reviewed.
Raymond
Raymond Hettinger wrote:
- Removed caching of TimeRE (and thus LocaleTime) in _strptime.py to
- fix a locale related bug in the test suite. Although another patch
- was needed to actually fix the problem, the cache code was not
- restored.
FWIW, I would feel safer if the cache code were restored. That code has been around for while and the one defect is known. In contrast, the "ripping it out" touched a lot of code and has not been thoroughly reviewed.
One argument for not putting it back: I realized that it is not totally thread-safe because of the laziness of the figuring out the locale info (although switching the locale while running threads you are asking for trouble). While there is no specific thread-safety claims, I would rather work the code to make it thread-safe before re-introducing caching.
But if people feel otherwise it is easy to put back in. I am abstaining from making any form of a vote on this since to not have a warped bias towards one side.
-Brett
- Removed caching of TimeRE (and thus LocaleTime) in _strptime.py to
- fix a locale related bug in the test suite. Although another patch
- was needed to actually fix the problem, the cache code was not
- restored.
FWIW, I would feel safer if the cache code were restored. That code has been around for while and the one defect is known. In contrast, the "ripping it out" touched a lot of code and has not been thoroughly reviewed.
One argument for not putting it back: I realized that it is not totally thread-safe because of the laziness of the figuring out the locale info (although switching the locale while running threads you are asking for trouble). While there is no specific thread-safety claims, I would rather work the code to make it thread-safe before re-introducing caching.
Besides being too late now, thread safety is another good reason to keep it out.
Raymond
################################################################# ################################################################# ################################################################# ##### ##### ##### ################################################################# ################################################################# #################################################################
On Fri, 2003-07-25 at 03:00, Brett C. wrote:
One argument for not putting it back: I realized that it is not totally thread-safe because of the laziness of the figuring out the locale info (although switching the locale while running threads you are asking for trouble). While there is no specific thread-safety claims, I would rather work the code to make it thread-safe before re-introducing caching.
But if people feel otherwise it is easy to put back in. I am abstaining from making any form of a vote on this since to not have a warped bias towards one side.
At this point, the code's probably better off left out than left in. We don't have time for another release candidate, and if Brett's against putting it in, we need to defer to that.
-Barry
-
Barry Warsaw -
Brett C. -
Raymond Hettinger