[Python-Dev] 2.3rc1 delayed
Tue, 22 Jul 2003 13:29:40 -0700
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
> "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