Ordering python sets

[Tim Rowe]

2008/10/27  <bearophileHUGS at lycos.com>:
> Lie Ryan:
>
>>Oh no, the two dict implementation would work _exactly_ the same from the outside, they are transparently interchangeable. Only the performance characteristic differs because of the different implementation.<
>
> I don't agree with the general idea. If the operations done by your
> data structure have different computational complexity, then they are
> fit for different usages. When you program you must know what
> computational complexity has each of the operations of your data
> structyre, otherwise there's no way to know the complexity of your
> whole program, so instead of programming you are just become a mage
> that tries magical spells and hopes for the better.

No, when you program you know how you will be using the data
structure, so you can choose the implementation that's right for the
application. That's what the container libraries for other languages
do. At the moment, you just have one implementation, and have to hope
it's right for the job. Adding an *optional* parameter that says, in
effect, "I want this list optimised for writes and reads at both ends"
or "I want this list optimised for fully random reads but writes only
at the end" doesn't *lose* you any information about what you're
programming with. Of course it's essential that the data structure has
identican /functional/ behaviour whatever optimisation you use. Other
languages can enforce that, but Python programmers are used to taking
care of that side of things for themselves.

> So I don't accept
> so much different data structures to have the same name. That's why
> I'll never appreciate the Python list type to be named list instead of
> array, despite it supports more or less all the functions you expect
> from an abstract list type.

They're not different data structures from the client point of view.
"More or less" all the functions wouldn't be enough.

-- 
Tim Rowe