-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: > Tres Seaver wrote: > >>Philipp von Weitershausen wrote: >> >>>>Log message for revision 68244: >>>> Fix a test that was testing wrong behaviour: primitive types >>>> 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) >> >>>>+ assert ec.evaluate('x | python:int') == 0 >> >>Wait a minute -- that isn't a path expression there! > > > Yes it is. This line could explicitly written as: > > assert ec.evaluate('path: x | python:int') == 0 > > The python: expression is just part of the path expression. > > >>The '|' is not supposed to change the rules for evaluation of the >>subexpressions! > > > It doesn't change the rules for the evaluation of the subexpressions > themselves. But it might easily change the rules of what happens to the > result of the expression afterwards. > > >>If >>'int' or the like were somehow avaialbe at module scope, or via >>'options' or another top-level name, then they should be called *when >>they are the last item in a path expression*. >> >>The test was actually correct beofore: because tne PathExpression, 'x', >>raises, the PythonExpression, 'int', is evalutated. The result of a >>subexpression is not suppoeed to be called, > > > No, not the result of a subexpression, but the result of the overall > path expression. That's how it works in both Zope 2 and Zope 3. Zope 2 > just special-cases primitive types.
If a subexpression returns a callable, you're telling me that you think the "top-level" expression is supposed to call it? That's nuts! The spec[1] says: > When a TALES path expression is evaluated, it attempts to traverse > each path, from left to right, until it succeeds or runs out of > paths. To traverse a path, it first fetches the object stored in the > variable. For each path segment, it traverses from the current object > to the subobject named by the path segment. > > Once a path has been successfully traversed, the resulting object is > the value of the expression. If it is a callable object, such as a > method or class, it is called. The semantics of traversal (and what it > means to be callable) are implementation-dependent. > > If a traversal step fails, evaluation immediately proceeds to the > next path. If there are no further paths, an error results. Calling the callable happens *before* attempting alternate expressions, not after. That is partly because the *call* might be what triggers the alternation. [1] http://www.zope.org/Wikis/DevSite/Projects/ZPT/TALES%20Specification%201.3 Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEciCT+gerLs4ltQ4RAhesAKDHpp1+XJRukZfRgp/wBrDyBA3/HACfRj4P k20UEFCRTzu++Bcyp015JDE= =nmpz -----END PGP SIGNATURE----- -- =================================================================== Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com _______________________________________________ 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 )