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
> 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.
>>'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.


- --
Tres Seaver          +1 202-558-7113          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


Tres Seaver          +1 202-558-7113          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to