On Wed, 30 Jul 2003 12:13:41 -0500 Evan Simpson <[EMAIL PROTECTED]> wrote:
> Jim Penny wrote: > > Well, that is exactly why it will be more confusing to everyone. A > > python programmer is not expecting them to be different, and a > > non-programmer has no idea of what keys and indices are, much less > > how they differ. > > The explanation isn't that hard, at least for a user with a basic > knowledge of data structures -- you usually use key: with a > dictionary, and item: with a sequence. The exception is when you have > an integer key in a dictionary. It is in fact not only hard to teach, it is impossible to use. Look, the ZPT programmer has no way of discovering whether the python programmer has returned a dictionary, a sequence, a Set, or anything else, much less what the key type is. Introspection is not available to a ZPT programmer. So, you are back to asking the python programmer, who just as well do the work. And why would I expect a ZPT person to have a basic knowledge of data structures? > > > Eeep, gad no. The python is horrible. The prefix syntax is equally > > horrible, unfamiliar, and ambiguous! For example, why does call: > > not have an argument > > Because I'm not passing an argument to the SQL statement. In my > implementation, the syntax is "call:arg1,arg2,...", where each > argument is required to be a variable name. Every prefixed path > element operates upon the current traversal object, using the argument > (if any) to the prefix. Here's a list that demonstrates: > > x/key:foo --> x['foo'] > x/item:0 --> x[0] > x/attr:foo --> x.foo > x/call:foo --> x(foo) > x/var:foo --> getattr(x, foo) or x[foo] (path traversal semantics) > x/fmt:%.2f --> '%.2f' % x > x/fmt:thousands_commas --> thousands_commas(x) > > > Doesn't it strike you as odd that sometimes the prefix denotes > > parameterization, and sometimes it denotes application? > > I hope that the list above makes the consistency clearer. No, it actually makes it clearer, and worse. It is an interesting notation, kind of, but hugely irregular, and that you and Chris are talking about two quite different semantics on top of a similar syntax does not help things in the least. One by one: key: and item: need to be combined, as they cannot be practically used by the ZPT programmer as separate entities, due to lack of introspection. var: is semantically clear, but I suspect will confuse the hell out of non-programmers. Frankly, and I freely admit that I have not a clue to the implementational details, I would prefer that key:, item:, and var: all be a single entity, say index: x/index:'foo' --> x['foo'] x/index:span_of_int ->x[span_of_int] x/index:foo --> x[foo] call: well, you have said that arguments are allowed, and must be only variable names. What is the reason for this? I assume that only positional parameters are permitted. With named parameters, this is the part I have fewest reservations about. Is there any reason to avoid parentheses however? Does using call: explicitly erase all magic name bindings (I hope so)? Why not x/call:(parameter_list)? There are several reasons to consider this. The primary one is that niladic calls are explicitly marked. Another reason, again with niladic calls is that x/call:()/foo makes is more clear that the foo attribute of x() is being requested, rather than that /foo is an argument to x. The final one is that it would probably permit much more general parameter lists, possibly including constants and/or named parameters. attr: looks clean enough. Combinations of attr: and call: made me think for a while, but, I don't see any obvious problems. fmt: is most irregular. First, it reverses the pattern of all the others and makes the stuff to the left the parameter. This may be OK for your intended audience. It may also confuse them totally. Why x/fmt:%.2f and not x/fmt:'%.2f'? As it stands, it takes either expression fragments starting with % or function names. Can I define my own functions, if so, how/where? Finally, can we come up with a better term than prefix. In conventional terminology, most of these are infix operations, except call, which may be a purely postfix. Jim Penny > > 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 ) > > _______________________________________________ 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 )
