2008/10/27 <[EMAIL PROTECTED]>: > 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 -- http://mail.python.org/mailman/listinfo/python-list
