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