Why are there no ordered dictionaries?

bonono at gmail.com bonono at gmail.com
Mon Nov 21 03:05:33 EST 2005


Fredrik Lundh wrote:
> bonono at gmail.com wrote:
>
> > Fredrik Lundh wrote:
> > > but you can easily generate an index when you need it:
> > >
> > >     index = dict(d)
> > >
> > >     name, type = index["pid"]
> > >     print name
> > >
> > > the index should take less than a microsecond to create, and since it
> > > points to the members of the original dict, it doesn't use much memory
> > > either...
> > >
> > Using the same logic, we don't need types other than string in a  DBMS
> > as we can always convert a string field into some other types when it
> > is needed.
>
> No, that's not the same logic.  The dict() in my example doesn't convert be-
> tween data types; it provides a new way to view an existing data structure.
> There's no parsing involved, nor any type guessing.  And given the use case,
> it's more than fast enough, and doesn't copy any data.
>
> If you think that's the same thing as parsing strings, you've completely missed
> the point.

Well, forget about the missing/not missing the point.

My point is, there are various of reasons why we need different data
types in an RDBMS, just the same as why we need list, dict. There is
nothing stop me from using a list as dict(just scan it till I find it),
why would I I create a dict(your new view of the same data) ? Coding
convenience, speed or whatever.

If I need the dict feature 90% of the time, and the list feature 10% of
the time. I want an ordered dict. Rather than a list and create this
new view every time and every where I want to use it as a dict.

parsing or not parsing is not the point, and parsing/converting is
still "create a new view" of an existing data structure.




More information about the Python-list mailing list