Paul Rubin wrote:
João Valverde <backu...@netcabo.pt> writes:
Interesting, thanks. The concept is not difficult to understand but
I'm not sure it would be preferable. A copy operation should have the
same cost as a "snapshot",
You mean a deep-copy? That is unnecessarily expensive; with a
functional structure you can snapshot (or copy) by copying a single
pointer.
Shallow copy...
undo is kind of redundant and multithreading... don't see a
compelling use that would justify it.
Here is one:
http://groups.google.com/group/comp.lang.python/msg/1fbe66701e4bc65b
I just skimmed that but if someone really needs multithreading for such
intensive processing without wanting a database, fair enough I guess.
Have you considered how the syntax would work in Python by the way? This:
new_tree = old_tree.insert(object)
Just looks wrong.
It looks fine to me. Obviously you could support a wrapper with
a mutating slot that holds a pointer to the tree.
I didn't get the last part, sorry. But I think you'd have a lot of users
annoyed that the interface is similar to a list yet their objects
mysteriously disappear. To me, tree.insert() implies mutability but I
defer that to others like yourself with more experience in Python than me.
--
http://mail.python.org/mailman/listinfo/python-list
