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

[Evan Simpson]

Jim Penny wrote:
> And why would I expect a ZPT person to have a basic knowledge of data
> structures?

In my view, this whole idea is primarily aimed at programmers.  I fully 
expect that non-programmer ZPT people will be able to ignore this stuff, 
apart from being handed a small set of idioms by the programmer.  Paths 
that can make use of these features are going to be constructed by 
programmers, and used as black boxes by ZPT people.

The driving rationale behind most of the prefixes that I implemented is 
to provide explicit spellings for things that have bitten myself and 
other programmers in practice. 'key', 'item', and 'attr' let us specify 
access methods when traversal magic fails (eg. method names clashing 
with keys, no way to access sequence items), and 'call' lets us traverse 
through simple data-access methods.  'var' is just a less-cryptic 
version of '?'-prefixed path elements.

Several of your objections/suggestions involve the distinction between a 
string and a name, as in:

> x/index:'foo'  -->  x['foo']
> x/index:span_of_int  ->x[span_of_int]
> x/index:foo    --> x[foo]

I'd rather not introduce additional punctuation (quotes or parens) if I 
can help it -- TAL and TALES both have a tradition of minimalist syntax, 
and it keeps parsing simple.  Also, as soon as you add delimiters, you 
add quoting issues, and TALES has enough of those already.

> call: well, you have said that arguments are allowed, and must be only
> variable names.  What is the reason for this?

To keep things simple.  There's a clearly visible slippery slope here, 
and I hope to stay off of it, since it leads to full-on Python in the 
middle of a path, which would be a nightmare.  Names-only takes care of 
the most common case, while allowing for dead-simple parsing 
(arg.split(',') then validate each name).

> Does using call: explicitly erase all magic name bindings  (I hope so)?

I don't know what you mean, here.

> 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?

'fmt' is a quick-and-dirty implementation, and most likely to change. 
It was almost certainly a mistake to conflate the standard formatting 
functions with Python string formatting.  I don't agree that it reverses 
the pattern, though -- to me, it's "apply *this* formatting operation to 
the current object", much like 'key' is "fetch *this* key from the 
current object".

One of my to-do's on this idea is syntax allowing prefix strings to be 
associated with an implementation within a template, possibly overriding 
the default associations.  In particular, this would allow you to make a 
prefix for a collection of your own functions.

> 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.

'prefix' refers to the syntax, not the operations.  In my source code 
comments, I refer to "prefixed path elements".  A better name would be 
welcome :-)

Cheers,

Evan @ 4-am