[Zope-dev] Re: TALES idea: tuple unpacking

[Jim Penny]

On Wed, 30 Jul 2003 12:13:41 -0500
Evan Simpson <evan@4-am.com> 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  -  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 )
> 
>