Re: [Zope-dev] Re: [Vote] PEP308 voting began
Paul Winkler wrote: +sys.maxint ugly python expressions in ZPT is to me a clear signal that you need to refactor and that's a GOOD THING. And refactoring is easy when you can just start by copy / pasting the python expressions into a Script. If they were some new-fangled if: then: else: syntax in TAL, you'd have to rewrite from scratch... and we're right back in the mess we got into with DTML: the poor developer is forced to learn many ways of doing the same thing. +OO (that's infinity in case it's not clear...) cheers, Chris ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: [Vote] PEP308 voting began
Lennart Regebro wrote at 2003-3-7 15:57 +0100: 1. Python is kept as is. 2. To support one-line if-else in attributes in ZPT, the python expressions used in ZPT imports an extra method. This method can be called whetever people want it toi be called, but for claritys sake lets call it 'if_else' if_else(expression, true_result, false_result) We have this function. It is called test (and more flexible than your proposal). It causes occasional questions on the mailing lists because it does not behave as one expects of an if-then-else. The main problem: if existence_of_some_object then: expression_depending_on_this_object else: alternative_expression cannot be expressed with test (or whatever function, unless Python changes function call semantics). *Provided*, expression_depending_on_this_object does not evaluate to a Python false value, existence_of_some_object and expression_depending_on_this_object or alternative_expression can be used. However, this is less clear (than an explicit if-then-else expression) and error prone (due to the *provided* condition). Dieter ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: [Vote] PEP308 voting began
On Fri, Mar 07, 2003 at 07:33:44AM +0100, Joachim Werner wrote: If I understood the intentions of ZPT right one of the ideas was to get rid of too much application logic in the template. But currently ZPT seems to be extended to become very similiar in functionality to DTML. I'd prefer to see an approach where Python is used wherever it makes sense and ZPT is kept as simple and stupid as possible. +sys.maxint ugly python expressions in ZPT is to me a clear signal that you need to refactor and that's a GOOD THING. And refactoring is easy when you can just start by copy / pasting the python expressions into a Script. If they were some new-fangled if: then: else: syntax in TAL, you'd have to rewrite from scratch... and we're right back in the mess we got into with DTML: the poor developer is forced to learn many ways of doing the same thing. -- Paul Winkler http://www.slinkp.com look! up in the sky! it's secretary The Archer of Doom (randomhero courtesy isometric.spaceninja.com) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] Re: [Vote] PEP308 voting began
Steve Alexander wrote: This is possible. But, the problem remains that both a and b (in your example above) are evaluated. I don't see the problem with that, unless a or b actually do stuff, and modify stuff, and if it does, in ZPT it should then be put into a script, since the template itself shouldn't contain any business logic. I can see the use of a one-line if-else syntax in ZPT as a way to set an attribute without making a specific pythons script just for such a small piece of code, and this will do it. If you want to *DO* different stuff depending on a condition, that shouldn't be in the template. Also, Evan tells me that this already exists in python: expressions, and is called test(). So, problem solved, no additional uglyfication of Python is needed. :) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Vote] PEP308 voting began
Evan Simpson wrote:
Guido van Rossum wrote:
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python. If you can have a
not:.. expression, surely you can have an if:..:then:..:else:..
expression.
Now that you point it out, it's not even hard. Here's a
proof-of-concept, with really awful parsing (it obviously breaks on
nested if: then: else:), that actually works:
class IfExpr:
def __init__(self, name, expr, compiler):
self._s = expr = expr.lstrip()
m = re.match('(.*) then:(.*) else:(.*)', expr)
if m is not None:
condexpr, thenexpr, elseexpr = m.groups()
self._cond = compiler.compile(condexpr)
self._then = compiler.compile(thenexpr)
self._else = compiler.compile(elseexpr)
def __call__(self, econtext):
if econtext.evaluateBoolean(self._cond):
return econtext.evaluate(self._then)
return econtext.evaluate(self._else)
(Tested with
div tal:replace=if:options/x then:string:yes else:string:no)
Is this worth a robust implementation, ZPT folks?
I think so. Iam much too often using python:test( just for simple
condition testing.
Cheers,
Evan @ 4-am
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] Re: [Vote] PEP308 voting began
(Tested with div tal:replace=if:options/x then:string:yes else:string:no) There are an awful lot of colons in there :-) Here's an off-the-wall idea: div tal:replace=talif tal:if=options/x tal:true=string:yes tal:false=string:no This looks better as a tal:tag tal:block replace=talif if=options/x true=string:yes false=string:no Or, if you only use this kind of thing with tal:replace, tal:content and tal:define. tal:block defineif=foo options/x true=string:yes false=string:no Of course, none of this helps for tal:attributes. -- Steve Alexander ___ Zope-Dev maillist - [EMAIL PROTECTED] 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: [Vote] PEP308 voting began
Guido van Rossum wrote:
IMO TALES should solve this for itself by introducing an if/then/else
expression form rather than depending on Python. If you can have a
not:.. expression, surely you can have an if:..:then:..:else:..
expression.
Now that you point it out, it's not even hard. Here's a
proof-of-concept, with really awful parsing (it obviously breaks on
nested if: then: else:), that actually works:
class IfExpr:
def __init__(self, name, expr, compiler):
self._s = expr = expr.lstrip()
m = re.match('(.*) then:(.*) else:(.*)', expr)
if m is not None:
condexpr, thenexpr, elseexpr = m.groups()
self._cond = compiler.compile(condexpr)
self._then = compiler.compile(thenexpr)
self._else = compiler.compile(elseexpr)
def __call__(self, econtext):
if econtext.evaluateBoolean(self._cond):
return econtext.evaluate(self._then)
return econtext.evaluate(self._else)
(Tested with
div tal:replace=if:options/x then:string:yes else:string:no)
Is this worth a robust implementation, ZPT folks?
Cheers,
Evan @ 4-am
___
Zope-Dev maillist - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] Re: [Vote] PEP308 voting began
On Tue, Mar 04, 2003 at 03:21:57PM -0600, Evan Simpson wrote: Is this worth a robust implementation, ZPT folks? maybe, but i'd rather first wait and see how the PEP goes. it would suck to have to constantly deal with two totally different flavors of ternary. -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
