[Zope-dev] New(ish) Windows test failures on Zope trunk

[Tim Peters]

I see two test failures today on Zope(2) trunk, WinXP, Python version
doesn't matter (same thing under 2.3.5 & 2.4.2).

Failure in test testRegisterTranslations
(zope.app.i18n.tests.testi18ndirectives.DirectivesTest)
Traceback (most recent call last):
  File "C:\Code\Zope\lib/python\zope\app\i18n\tests\testi18ndirectives.py",
line 55, in testRegisterTranslations
    eq(util._catalogs, {'en': [unicode(path)]})
  File "C:\python23\lib\unittest.py", line 302, in failUnlessEqual
    raise self.failureException, \
AssertionError: {u'en':
[u'C:\\Code\\Zope\\lib\\python\\zope\\i18n\\tests\\locale\\en\\LC_MESSAGES\\zope-i18n.mo']}
!=
{'en': [u'C:\\Code\\Zope\\lib/python\\zope\\i18n\\tests\\locale\\en\\LC_MESSAGES\\zope-i18n.mo']}

One dict has a Unicode key there while the other dict doesn't, and the
"python" part of the value is preceded by a backslash in one but a
forward slash in the other.

Then:

Failure in test checkDuplicate (zope.configuration.config.ConfigurationContext)
Failed doctest test for
zope.configuration.config.ConfigurationContext.checkDuplicate
  File "C:\Code\Zope\lib/python\zope\configuration\config.py", line
259, in checkDuplicate

File "C:\Code\Zope\lib/python\zope\configuration\config.py", line 281,
in zope.configuration.config.ConfigurationContext
.checkDuplicate
Failed example:
    try:
      c.checkDuplicate(d + os.path.normpath('/bar.zcml'))
    except ConfigurationError, e:
      str(e).endswith("bar.zcml' included more than once")
Expected:
    True
Got nothing

_Looks_ like the test expected ConfigurationError to be raised, but
that ConfigurationError was not raised.

Oddly enough, I believe this is related to the first test failure. 
Dumping some prints in checkDuplicate() shows that, when the test
fails, `path` is

'C:\\Code\\Zope\\lib\\python\\zope\\configuration\\bar.zcml'

and self._seen_files is a set with two elements:

'C:\\Code\\Zope\\lib/python\\zope\\configuration\\bar.zcml'
'\\foo.zcml'

As in the first test too, the character preceding the "python" part
differs.  The path passed is indeed not in the set of _seen_files, so
ConfigurationError is indeed not raised.

No idea where this slash-vs-backslash confusion ultimately comes from,
though.  Who recently checked code in hard-coding "/" as a path
separator?