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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )