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)
  

Changed:
  U   
Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py

-=-
Modified: 
Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py
===================================================================
--- 
Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py
 2006-05-22 15:49:01 UTC (rev 68243)
+++ 
Zope/branches/ajung-zpt-end-game/lib/python/Products/PageTemplates/tests/testExpressions.py
 2006-05-22 18:52:50 UTC (rev 68244)
@@ -76,36 +76,7 @@
         '''Test hybrid path expressions'''
         ec = self.ec
         assert ec.evaluate('x | python:1+1') == 2
-
-        # XXX The following test fails because int here is called
-        # which yields 0, not the int type. Why is it called? Because
-        # PathExpr calls everything that's not on the trees by the
-        # time it has counted to three.
-        assert ec.evaluate('x | python:int') == int
-
-        # The whole expression is a PathExpr with two subexpressions:
-        # a SubPathExpr and a PythonExpr.  The first fails as
-        # intended, so the second is evaluated.  The result is called.
-        # The old PathExpr didn't do that.  Specifically, it wouldn't
-        # call builtin types (str, unicode, dict, list, tuple, bool).
-        # There are two things we can do about this now:
-
-        # a) Nothing. Accept the incompatibility from Zope 2.9 to
-        #    2.10.  Of course, this might break existing code, but
-        #    there are ways to make code compatible with 2.9 and 2.10:
-        #    Add a nocall: before the python: expression (if that's
-        #    possible?!?).  You just have to know about these things
-        #    beforehand.
-        
-        # b) Provide our own PathExpr implementation that does not
-        #    blindly call primitive types.  We would have to keep this
-        #    code in Zope 2 forever which means there'd be an
-        #    incompatibility between Zope 2 and Zope 3 ZPTs forever.
-
-        # I'm leaning towards option a). Given that this only turns
-        # out to be a problem with builtin types, the breakage is
-        # quite limited.
-
+        assert ec.evaluate('x | python:int') == 0
         assert ec.evaluate('x | string:x') == 'x'
         assert ec.evaluate('x | string:$one') == '1'
         assert ec.evaluate('x | not:exists:x')

_______________________________________________
Zope-Checkins maillist  -  Zope-Checkins@zope.org
http://mail.zope.org/mailman/listinfo/zope-checkins

Reply via email to