Why are there no ordered dictionaries?

[Bengt Richter]

On 21 Nov 2005 01:54:38 -0800, "bonono at gmail.com" <bonono at gmail.com> wrote:

>
>Fredrik Lundh wrote:
>> bonono at gmail.com wrote:
>>
>> > If I need the dict feature 90% of the time, and the list feature 10% of
>> > the time.
>>
>> Wasn't your use case that you wanted to specify form fields in
>> a given order (LIST), render a default view of the form in that
>> order (LIST), and, later on, access the field specifiers in an
>> arbitrary order, based on their key (DICT).  Sure looks like it's
>> the LIST aspect that's important here...
>Yes. But whether LIST aspect or DICT is important is well, opinion. So
>let's leave it there.

>>
>> > 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.
>>
>> You want an ordered dict because you say you want one, not be-
>> cause it's the best way to address your use case.  That's fine, but
>> it's not really related to the question asked in the subject line.
>Again, best way is decided by ME. If I am entering a coding contest
>which is organized by YOU, that is a different story. As for related to
>the subject line, since when I said my preference or use case has
>anything to do with the subject line ? I have said in another post that
>I don't think there should be  one in the standard library, which is
>directly about the subject line.
Ok, so if not in the standard library, what is the problem? Can't find what
you want with google and PyPI etc.? Or haven't really settled on what your
_requirements_ are? That seems to be the primary problem people who complain
with "why no sprollificator mode?" questions. They don't know what they really
mean when it comes down to a DYFR (Define Your Felicitous Requirements) challenge.
So DYFR ;-)
Then someone can take less time than many of these posts takes to make a
list subclass that also acts like the dict when you want or a dict subclass that
also acts like a list when you want. Which methods from which would you like
as-is, and which modified? Any additional methods or properties? DYFR ;-)

>
>>
>> > parsing or not parsing is not the point, and parsing/converting is
>> > still "create a new view" of an existing data structure.
>>
So you'd like the mechanics to be automated and hidden? Then you need to
DYFR for using the black box you want. Methods, semantics.

>> Copying the entire data structure hardly qualifies as "creating a
>> new view".  dict() doesn't do that; in this use case, it doesn't cost
>> you anything to use it.
>doesn't cost me anything ? That is good news to me.
Well, if you want something specific, it WILL cost you the effort to DYFR in detail ;-)

( posting delayed >12 hrs due to news server prob ;-/ )

Regards,
Bengt Richter