Further questions on dictionaries, namespaces, etc.

[Talin]

Thanks to everyone for pointing out my bone-headed errors :) I don't 
*usually* make that sort of mistake...

What I'm attempting to do is create an implentation of the unification 
algorithm. Now, its fairly straightforward to do unification on my own 
custom types, all I have to do is define a unify() method for each class:

    def unify( self, other, bindings ):
       ...

However, this doesn't work so well when the objects being unified are 
built-in python types (tuples, integers, etc.) This requires the 
"un-pythonic" testing of each individual type and then calling the 
appropriate unification function for the given type.

Another thing that is important is that this particular unifier supports 
commutative functions (which accept their arguments in any order), which 
is what the permutation stuff is for. (I haven't done associativity yet, 
still working on it.) The unifier is structured as a stack of 
generators, each returning all possible matches. This allows the higher 
levels of the unifier to backtrack by processing alternatives produced 
by the lower-level generators.

So here's my list of further questions:

1) Is there are better way to do "functional overloading" on built-in 
types than using a whole series of "if type( x ) is y".

2) Is there an easy way to determine if a given object has a callable 
method named "unify"? I know how to determine if there's an attribute 
with a name, but not how to determine whether or not that attribute is 
callable.

3) The "bindings" object is a dictionary that is constructed as the 
unification proceeds. (So for example, if I attempt to unify "x + 1" 
with "2 + 1" it will have the binding "x : 2" in the dictionary.

I want this bindings object to behave like a function call scope - in 
that you can "see" the variables in the enclosing scope. In fact, I'd 
like to be able to use a regular python namespace (such as a module) as 
the enclosing scope, so that the unification algorithm has access to all 
of the variable definitions within that module. (Again, this is part of 
the notion that I want to be able to do unification operations on normal 
python data structures, rather than specially "wrapped" types.)

In fact, I had thought about the idea of the bindings being an actual 
Python "module" object, however that doesn't appear to be possible (or 
what I want for that matter.) Similarly, being able to take the local 
function scope and capture it in a closure and export that to the 
outside world was also something I briefly pondered.

Because of the backtracking nature of the matcher, I need to be able to 
"undefine" bindings that have been previously defined. The way I am 
currently doing this is to create a new "scope" each time I add a new 
binding, where the new scope's "parent" is the previous scope. (So in 
fact my dictionary has only one entry in it.) Something like this:

    for new_bindings in generate_matches( a, b, old_bindings ):
       ...

If none of the alternatives pan out, it simply discards "new_bindings" 
and reverts back to the old_bindings.

So my question here is: Do I want to continue using a subclass of dict 
for this, or something more exotic?

4) I've seen a couple of code examples on the net where people use the 
idiom "lambda x: (for x in [])" to represent a "null" iterator, i.e. one 
that immediately terminates. How is this any different from simply 
returning "()"? (Or range( n, n ) for that matter.) Which one is the 
most efficient? And if they are different, how about adding a null 
iterator to itertools :)

-- Talin