adapter to be present even when traversing just dicts. No problem, we can
set it up quite easily.

This basically finishes this branch. All tests pass, some 3rd party apps
have been tested with it. There are a few test failures in the CMF and
others (e.g. Plone), but that's mostly "their fault" (incorrect or
unexpected usage of certain things).

- Apply usual tal:omit-tag fix to make the element carrying i18n:name go away
- Disable a test that was testing madness (mixing unicode and encoded strings)

* tal:replace now emits something different (optTag)
* constructs with i18n:name emits more complicated bytecode (i18nVariable, etc.)
  to cope with behavioural changes (see http://zope.org/Collectors/Zope3-dev/301)
* probably some more that aren't very interesting (if these any of this is
  interesting at all)

i18n:name and i18n:translate on the same element is now supported. Moreover,
i18n:translate isn't automatically assumed for those elements with i18n:name.
Also, the element that i18n:name is on isn't automatically removed anymore.
You'll have to use tal:omit-tag to explicitly make it go away.

For more info, see http://zope.org/Collectors/Zope3-dev/301.

into something general, make PathExpr deal with Zope 2 exceptions.

is fixed. Because then we need to have an ITraversable registered evne when
traversing dicts. For now this doesn't do harm.

(boboTraverseAwareSimpleTraverse) with a request. Since zope.app has
already solved this problem (and I copied zope.app's approach in the
traverser), we can just simply reuse zope.app's code here. Yes, it
adds another dependency on zope.app, but at least we're not duplicating
code.

All Zope 2 tests should be passing now...

in http://mail.zope.org/pipermail/zope-dev/2006-May/027493.html.
Disable the corresponding tests therefore.

path expressions where the alternate expression wasn't a PathExpr is not called.
See http://www.zope.org/Collectors/Zope/538, http://svn.zope.org/?view=rev&rev=22855
and http://www.zope.org/Collectors/Zope3-dev/638.

object or rendering it "with namespace". This also fixes the previously added
test case where importing, instantiating and rendering DateTime would fail.

a method on it. This currently fails, primarily because of a stupidity
in zope.traversing.adapters.traversePathElement and secondarily because
of other funkiness.

by providing PathIterator which (every much like the old PathIterator.Iterator
class) handles its own traversal (only now we use the Zope 3 traversal hooks).

werent' called if they were the result of a path expression, while
all other callables were called. This tests now tests the correct
behaviour (which happens to be already implemented by the Zope 3
TALES engine)

regarding our plans for the other iterator BBB code