[Zope-dev] Re: Zope 3 ZPTs in Zope 2: Nearly done

[Philipp von Weitershausen]

Tres Seaver wrote:
> Re: Empty path elements:
> 
> Zope2 uses them at the beginning of a path to indicate traversal from
> the root.

Sure, in restrictedTraverse and the like. But not in TALES expressions.
While you can start a TALES expression on a /, the empty path element at
the beginning stands for the global namespace. Hence, path:foo/bar and
path:/foo/bar are identical. Specially, you still have to write root/bla
or /root/bla to traverse from the root object.

>  -1 to dropping that case (it is the one which makes
> '/foo/bar' behave orthagonally).  Havinng blank elements work as no-ops
> also makes them behave predictably:  this is what command shells (sane
> ones, anyway) do with them.  E.g.:
> 
>   $ ls /path/to//foo
> 
> yiels the same results as:
> 
>   $ ls /path/to/foo
> 
> So -0 to dropping the current blank traversal behavior at all.
> Therefore, +0 to modifying Z3's version to allow the same behavior (I
> think Zope2's version is more correct).

I would tend to agree, however, Fred must've had a reason when he added
the check for empty path elements in zope.tales.expressions:

 26551   srichter class SubPathExpr(object):
 12874   philikon
  9658      matth     def __init__(self, path, traverser, engine):
  9637      matth         self._traverser = traverser
  9658      matth         self._engine = engine
 10598     stevea
  9637      matth         # Parse path
  9658      matth         compiledpath = []
  9658      matth         currentpath = []
  9658      matth         for element in str(path).strip().split('/'):
 26722     fdrake             if not element:
 26722     fdrake                 raise engine.getCompilerError()(
 26722     fdrake                     'Path element may not be empty in
%r' % path)

r26722 unfortunately doesn't have a log message that might hint at the
reason. It does feature an extensive test
(testEmptyPathSegmentRaisesCompilerError) for this change though.

Perhaps Fred can shed some light on this issue? (CCing him)

> Re: calling primitive types which are at the end of a path expression.
> 
> They should be called, as should any other callable at the end of a path
> expression;  anything else is a hard-to-explain bit of special case
> hackery.  The ZPT spec has *always* read so.  +1 to fixing both / either
> Z2 or Z3 to make this uniformly so.  BBB be damned in this case, as the
> behavior (not calling the primitiive type) is contrary to spec.

Right. Basically, we'd be fixing a bug because the current Zope 2
behaviour is contradicting spec. Too bad this behaviour is documented in
a test... oh well, tests can have bugs, too. I will fix the test in Zope
2.10 to work with Zope 3's (correct) behaviour. I should probalby also
fix Zope 2.9's behaviour if we consider this a bug?!?

Philipp