[Python-Dev] Re: Sets: elt in dict, lst.include

[Guido van Rossum]

> > > Dictionaries are not sequences. I wonder what order a user of
> > > for k,v in dict: (or whatever other of this proposal you choose)
> > > will expect...
> > 
> > The same order that for k,v in dict.items() will yield, of course.
> 
> And then people find out that the order has some sorting
> properties and start to use it... "how to sort a dictionary?"
> comes up again, every now and then.

I don't understand why you bring this up.  We're not revealing
anything new here, the random order of dict items has always been part
of the language.  The answer to "how to sort a dict" should be "copy
it into a list and sort that."

Or am I missing something?

> > > Please also take into account that dictionaries are *mutable*
> > > and their internal state is not defined to e.g. not change due to
> > > lookups (take the string optimization for example...), so exposing
> > > PyDict_Next() in any to Python will cause trouble. In the end,
> > > you will need to create a list or tuple to iterate over one way
> > > or another, so why bother overloading for-loops w/r to dictionaries ?
> > 
> > Actually, I was going to propose to play dangerously here: the
> > 
> >     for k:v in dict: ...
> > 
> > syntax I proposed in my previous message should indeed expose
> > PyDict_Next().  It should be a big speed-up, and I'm expecting (though
> > don't have much proof) that most loops over dicts don't mutate the
> > dict.
> > 
> > Maybe we could add a flag to the dict that issues an error when a new
> > key is inserted during such a for loop?  (I don't think the key order
> > can be affected when a key is *deleted*.)
> 
> You mean: mark it read-only ? That would be a "nice to have"
> property for a lot of mutable types indeed -- sort of like
> low-level locks. This would be another candidate for an object flag
> (much like the one Fred wants to introduce for weak referenced
> objects).

Yes.

--Guido van Rossum (home page: http://www.python.org/~guido/)