[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py Fix a test that was testing wrong behaviour: primitive types

2006-05-25 Thread Philipp von Weitershausen
Tres Seaver wrote:
 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

You're absolutely right. I filed a collector issue for Zope 3:
http://www.zope.org/Collectors/Zope3-dev/638

This will be fixed soon in Zope 3.

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 )


[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py Fix a test that was testing wrong behaviour: primitive types

2006-05-22 Thread Philipp von Weitershausen
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.

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 )


[Zope-dev] Re: SVN: Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py Fix a test that was testing wrong behaviour: primitive types

2006-05-22 Thread Tres Seaver
-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 Designhttp://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 Designhttp://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 )