Greg Ewing wrote:
Paul Moore wrote:
I'd rather see a solution which addressed the
wider visitor use case (I think I just sprained my back bending over
backwards to avoid mentioning generic functions :-))
Speaking of generic functions, while thinking about the
recent discussion on proxy objects, it occurred to me
that this is something you can do with an OO system
that you can't do so easily with a generic function
system. If the operations being proxied were generic
functions rather than methods, you'd have to override
them all individually instead of having a central point
to catch them all.
I don't think it would actually be that much worse - something like
typetools.ProxyMixin would just involve a whole series of register calls
instead of method definitions. I wouldn't expect the total amount of
code involved to change much.
That said, a recursive flatten() implementation is indeed a problem that
generic functions are well suited to solving - have the default
implementation attempt to iterate over the passed in object yielding its
contents, yielding the object itself only if iteration fails, and then,
for the types the application wishes to consider atomic, register an
alternative implementation that just yields the object without
attempting to iterate over it.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
