Tim Peters wrote: > Today (CVS HEAD), test_strptime is failing on WinXP, in release and debug > test runs, but only when I run the full test suite: > > test test_strptime failed -- Traceback (most recent call last): > File "C:\Code\python\lib\test\test_strptime.py", line 289, in > test_bad_timezone > self.failUnlessEqual(tz_value, -1) > AssertionError: 0 != -1 > > > If I run it in isolation, it does not fail: > > C:\Code\python\PCbuild>python ../lib/test/test_strptime.py > test_basic (__main__.getlang_Tests) ... ok > test_am_pm (__main__.LocaleTime_Tests) ... ok > test_date_time (__main__.LocaleTime_Tests) ... ok > test_lang (__main__.LocaleTime_Tests) ... ok > test_month (__main__.LocaleTime_Tests) ... ok > test_timezone (__main__.LocaleTime_Tests) ... ok > test_weekday (__main__.LocaleTime_Tests) ... ok > test_blankpattern (__main__.TimeRETests) ... ok > test_compile (__main__.TimeRETests) ... ok > test_matching_with_escapes (__main__.TimeRETests) ... ok > test_pattern (__main__.TimeRETests) ... ok > test_pattern_escaping (__main__.TimeRETests) ... ok > test_TypeError (__main__.StrptimeTests) ... ok > test_bad_timezone (__main__.StrptimeTests) ... ok > test_caseinsensitive (__main__.StrptimeTests) ... ok > test_date (__main__.StrptimeTests) ... ok > test_date_time (__main__.StrptimeTests) ... ok > test_day (__main__.StrptimeTests) ... ok > test_defaults (__main__.StrptimeTests) ... ok > test_escaping (__main__.StrptimeTests) ... ok > test_hour (__main__.StrptimeTests) ... ok > test_julian (__main__.StrptimeTests) ... ok > test_minute (__main__.StrptimeTests) ... ok > test_month (__main__.StrptimeTests) ... ok > test_percent (__main__.StrptimeTests) ... ok > test_second (__main__.StrptimeTests) ... ok > test_time (__main__.StrptimeTests) ... ok > test_timezone (__main__.StrptimeTests) ... ok > test_unconverteddata (__main__.StrptimeTests) ... ok > test_weekday (__main__.StrptimeTests) ... ok > test_year (__main__.StrptimeTests) ... ok > test_twelve_noon_midnight (__main__.Strptime12AMPMTests) ... ok > test_all_julian_days (__main__.JulianTests) ... ok > test_day_of_week_calculation (__main__.CalculationTests) ... ok > test_gregorian_calculation (__main__.CalculationTests) ... ok > test_julian_calculation (__main__.CalculationTests) ... ok > test_new_localetime (__main__.CacheTests) ... ok > test_regex_cleanup (__main__.CacheTests) ... ok > test_time_re_recreation (__main__.CacheTests) ... ok > > ---------------------------------------------------------------------- > Ran 39 tests in 0.219s > > OK > > The regrtest framework alone is not making it fail either: > > C:\Code\python\PCbuild>python ../lib/test/regrtest.py test_strptime > test_strptime > 1 test OK. > > Best guess is that some earlier test (in a full test run) is screwing up > locale in a way test_strptime can't recover from. Maybe that's enough so > that you know who you are <wink>. > =) I like Tim's assessment. Best way to test that theory would be to clear the cache in _strptime. Tim, can you insert the lines:: print "***%s == %s ?" % (_strptime._TimeRE_cache.locale_time.lang, _strptime._getlang()) _strptime._TimeRE_cache = _strptime.TimeRE() _strptime._regex_cache = {} in the function (line 282 should be fine; just as long as you do it before any calls to _strptime). That will state what the current language is set for LC_TIME and what the cache was created for (so we can see what is thought to be the settings) and then clear _strptime's cache. While the code tries to detect locale changes, it is possible it is not manifesting itself in a way that is detectable. If the clearing of the cache, and thus the rebuild of all values that strptime uses, solves this than that's what is happening, I think. -Brett
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4