It would be nice if **kw arguments collected in a function / method signature were collected as an ordered dictionary rather than ordinary dictionary.
Main use case, currently (I believe) the odict constructor doesn't guarantee to preserve ordering if created with keyword arguments:
odict(key=value, key2=value, key3=value)
My use case - I'd like to preserve the ordering to reproduce exactly the order of arguments for the Mock module representation of the objects are used. Because the order of iterating over arguments isn't the same as they are passed in representations can't be compared in tests reliably across Python versions / implementations.
> It would be nice if **kw arguments collected in a function / method signature > were collected as an ordered dictionary rather than ordinary dictionary.
I think that would be nice, but until ordered dicts get a C implementation, it might greatly impair performance.
> Main use case, currently (I believe) the odict constructor doesn't guarantee > to preserve ordering if created with keyword arguments:
> My use case - I'd like to preserve the ordering to reproduce exactly the > order of arguments for the Mock module representation of the objects > are used. Because the order of iterating over arguments isn't the same > as they are passed in representations can't be compared in tests > reliably across Python versions / implementations.
> [Michael Foord] > > It would be nice if **kw arguments collected in a function / method > > signature were collected as an ordered dictionary rather than ordinary > > dictionary.
> I think that would be nice, but until ordered dicts get a C implementation, > it might greatly impair performance.
What is/are the main issue(s) about that?
> > Main use case, currently (I believe) the odict constructor doesn't > > guarantee to preserve ordering if created with keyword arguments:
More generally, no custom func/constructor can rely on **kwargs. Any order preserving application needs to require (name,value) pair lists instead of the (much nicer imo) kwarg syntax. This is especially pitiful for custom types.
> > My use case - I'd like to preserve the ordering to reproduce exactly the > > order of arguments for the Mock module representation of the objects > > are used. Because the order of iterating over arguments isn't the same > > as they are passed in representations can't be compared in tests > > reliably across Python versions / implementations.
> Sounds reasonable.
If only for printed feedback -- first of all to the developper itself -- I think this a sensible feature.
> Raymond
================================== OT: I take the opportunity to talk about something related. This is a data type that would be a kind of list/dict mix, maybe more, but basically ordered. Just discovered that Lua's table (http://lua-users.org/wiki/TablesTutorial) is this kind of thing; but iteration doesn't preserve order (background hash like for python dicts) for non-index keys.
Having very few CS knowledge, I wonder what kind of underlying data structure would easily allow this. As of know, I'm thinking at the following: * Keys could be anything "stringifiable", serializable or representable as an array of ints. * An issue is avoiding conflict between keys of != types, eg 1 vs '1'. * This would allow using trie algorithms (http://en.wikipedia.org/wiki/Trie), especially for item insertion/deletion/update/lookup. Even better may be a Patricia or a de la Briandais tree. Iteration is not an issue precisely because order is kept: it's walking the tree leaves. * Time efficiency is not my primary concern -- I just don't want it to be stupidly slow ;-) * I'm also interested in alternatives to implement basically ordered dicts, without any standard python dict in the background. And in (name:value) ordered collections as for namespace registers, or kwarg lists (cf Michael's need above).
Anyone interested to cooperate? [Aside python itself, my motivation is rather the fun of exploration, and a possible toy custom language I have in mind.]
> ================================== > OT: > I take the opportunity to talk about something related.
If you're going to change the subject, please make a new post starting a new thread; python-ideas is archived for future reference, and burying topics in other threads makes the archive less useful. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair _______________________________________________ Python-ideas mailing list Python-id...@python.org http://mail.python.org/mailman/listinfo/python-ideas
