No trees in the stdlib?
backup95 at netcabo.pt
Mon Jun 29 07:56:07 CEST 2009
Paul Rubin wrote:
> João Valverde <backup95 at 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
>> undo is kind of redundant and multithreading... don't see a
>> compelling use that would justify it.
> Here is one:
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.
More information about the Python-list