Roland Puntaier [mailto:[EMAIL PROTECTED] > Warren, can you please restate your point.
Hey Roland, where were you a few days ago ;-) I think most suggestions were valid, in their own context. Only yesterday, was I finally able to get it in perspective, so here goes: There are two idioms: a domain specific language, called Tr3 http://muse.com/tr3/Tr3%20Overview.pdf , and Python. The idioms both complement each other and conflict. Most of this thread has explored that conflict. Tr3 has three main components: a namespace tree, a directed graph of inputs and a directed graph of outputs. By analogy: the namespace functions like XML, inputs function like callbacks, and outputs function like standard procedures. The precursor to Tr3 was written C++. The inputs were script while the outputs were in C++. So, any changes in procedure required a recompile. The new version still allows C++ plugins, but the procedures can be written in Python. Inputs to Tr3 are queries to other parts of the namespace. By analogy, inputs behave like an Xpath query. So `a//z` searches for all descendants of `a` named `z`. The results of a query yields a list that can change state for the node on the tree which made the query. Another example, more in line with the title of this thread, is the query `a[:4]b`, which returns a list `[a[0].b, a[1].b, a[2].b, a[3].b]` Outputs are Python. This thread was my way of exploring to what degree that the `a[:4]b` of inputs could be applied to outputs as `a[:4]b()`. It would be idiomatic to Tr3 but not as idiomatic to Python. Here's why: What should this mean? if a[:4]b(): . Should it mean: if a[0].b() and a[1].b() and a[2].b() and a[3].b(): . or if a[0].b() or a[1].b() or a[2].b() or a[3].b(): . or if a[0].b(): . if a[1].b(): . if a[2].b(): . if a[3].b(): . Each interpretation could be justified. Thus, the implicit iteration is ambiguous. I am porting code that only uses this form a[:4]b() Which translates to: for i in range(4): a[i].b() There is only one interpretation and thus unambiguous. I have also explored writing client code that interprets `a[:4]b` as: if a[0].b() and a[1].b() and a[2].b() and a[3].b(): . A few algorithms, like Huffman codes, wind up looking much simpler, with implicit iterators. Be that as it may, making such algorithms easier to read may not be worth the cost of adding ambiguity to a general purpose procedural language. So, you're all right. Relax. Get outdoors. Fall in love. Make someone happy. And thanks again, \~/ -- http://mail.python.org/mailman/listinfo/python-list
