[Python-Dev] 2.3rc1 delayed

[Brett C.]

Tim Peters wrote:

> [Raymond Hettinger]
> 
>>Please forgive if I'm stating the obvious, but the failing tests
>>are the ones that should be changed, not the ones that are
>>"polluting" the environment.
>>
>>When I was working on test_warnings.py, I had found that other
>>tests had set warning filters without clearing them.  Rather than
>>alter the polluters, I fixed test_warnings so it either worked with
>>existing filters or temporarily set its own -- that way the test would
>>work in any combination with other tests.  In a way, the polluters
>>were helpful because they helped flag an unnecessary state
>>dependency in the test_suite.
>>
>>So if  test_strptime is going to be locale dependent, it should
>>temporarily set what it expects to find.
> 
> 
> I'm not sure it's as simple as that either.  For example, _strptime.py's
> LocaleTime class's .lang property caches the first value it sees, so that it
> will continue returning the same thing even if the user changes locale.   As
> an American, I don't know whether that's a feature or a bug.

Feature.  A LocaleTime instance is not to be used if the lang attribute 
does not match what _strptime._getlang returns.  _strptime.strptime 
checks this on each call to clear the cached TimeRE object it uses to 
generate its regexes.

> Given all the
> locale-aware code in _strptime.py, I have to guess that it *intended* to be
> locale-independent, and it's obvious that the test_strptime.py test that
> failed is trying like hell not to assume any particular locale is in effect:
> 
>     def test_lang(self):
>         # Make sure lang is set
>         self.failUnless(self.LT_ins.lang in
>                            (locale.getdefaultlocale()[0],
>                             locale.getlocale(locale.LC_TIME),
>                             ''),
>                         "Setting of lang failed")
> 
> Your guess about what that's testing is better than mine <wink>.
> 

The test is to make sure the lang attribute was set to what it should be 
set to; yes, it is that simple.  And the self.LT_ins object is in the 
setUp method and is recreated after every call so there is no worry of a 
stale instance.

-Brett