Added hint on where the segfault happens. My test output is irritating, it seems we end up with a cyclic aq_chain again :(

behaviour of BrowserView.  Well, when I say failing I should really say
segfaulting :/

  class MyView(BrowserView):

      __call__ = ViewPageTemplateFile('...')

work.

support since Zope 2.10)

  class Foo:
      __call__ = SomeCallableObject()

This is very useful for Zope 3 templates where this paradigm is used
all over the place. In fact, mapply simply uses this part of Zope 3's
__call__ finding logic. (I actually wish we could simply switch over to
Zope 3's mapply, but the call signatures aren't the same. Sigh.)

implementation from Zope 3.

that the publishTraverse method on the Zope3 implementation, which we use now,
works as expected).

it with light shims over the Zope 3 stuff.

Moved special __parent__ behaviour up to the browserview class, so all classes inheriting from it, gain this special behavior.

browserDefault implementations that were returning object_thats_not_self, ()
didnt' work.

towards OFS.Traversable and OFS.Application. Name them so.

Introduce a more generic implementation that's very very close to the Zope 3
one and works on objects that don't inherit from OFS.Traversable or support
acquisition (e.g. views, resources, etc.)