Reaching subtrees

François Pinard pinard at iro.umontreal.ca
Sat Sep 18 09:04:30 EDT 1999


"Darrell" <darrell at dorb.com> écrit:

> Not understanding why you like this [recursive tuple unpacking] so much.
> But happy that you do.

Thanks.  I like it because I have code that explore subtrees according to
literally hundreds of structural patterns (if not thousands when you put all
the programs together), and I even wrote a language to help me at this.  So,
it is a common problem for me, and I like expressing constraints fluently.

If Python allows me to easily name subtrees while picturing the skeleton
model, it means that I could use unadorned Python to write unusually legible
code for such things without having to recourse to special languages.
A Python application would have to be small, as implementing my language
revealed me how necessary it is to precondition how huge rule sets are
handled -- an important part of my effort was devoted to optimisation.

However, having contemplated Python in some more detail, there is still a few
important cases of structural patterns that my language implements, and that
do not seem to be easily representable with mere recursive tuple unpacking.
But I would guess that for many simple cases, Python would just suffice.

By the way, and quite unrelated to my own tool language, if recursive
tuple unpacking was accepting an immutable (instead of a variable) in
the skeleton as forcing an exact match instead of an assignment, and if
the same variable could be repeated in the skeleton and then, force an
identity check instead of an assignment, maybe that would make Python not
very far from Prolog unification :-).  Just a random thought, of course.

> Yes, this looks like standard python stuff.

I'll try to find a precise statement of this in Guido's reference manual.

> As you know if the tuples don't unpack correctly they throw an exception.
> Exceptions are slow so doing this on a large scale might be a problem.

I guess they might be slow because they have to somewhat scan the stack
back to find an exception catcher, but otherwise, if exceptions are caught
quite early on the stack, do they still have to be slow?  That would be
a little unfortunate, at least for my case.  I thought that `try:' could
become an important part of Python writing style.  It should rather not?

-- 
François Pinard   http://www.iro.umontreal.ca/~pinard





More information about the Python-list mailing list