On Thu, Jan 20, 2011 at 1:21 AM, Arnaud Delobelle wrote:

On 20 January 2011 04:29, Don Spaulding wrote:

...

Hi there python-ideas! Does it bother anyone else that it's so cumbersome to instantiate an OrderedDict with ordered data? >>> from collections import OrderedDict >>> OrderedDict(b=1,a=2) OrderedDict([('a', 2), ('b', 1)]) # Order lost. Boooo. >>> OrderedDict([('b',1),('a',2)]) OrderedDict([('b', 1), ('a', 2)]) Obviously, OrderedDict's __init__ method (like all other functions) never gets a chance to see the kwargs dict in the order it was specified. It's usually faked by accepting the sequence of (key, val) tuples, as above. I personally think it would be nice to be able to ask the interpreter to keep track of the order of the arguments to my function, something like: def sweet_function_name(*args, **kwargs, ***an_odict_of_kwargs): pass I'm not married to the syntax. What do you think about the idea?

FYI this was discussed before on this list at least once:

http://mail.python.org/pipermail/python-ideas/2009-April/004163.html

-- Arnaud

So it was. Thanks for that link. Am I to assume nothing ever came of that discussion?

On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano wrote:

I would be +0 on making **kwargs an ordered dict automatically, and -1 on adding ***ordered_kwargs. Because kwargs is mostly used only for argument passing, and generally with only a small number of items, it probably doesn't matter too much if it's slightly slower than an unordered dict.

Yeah, simply making the kwargs dict always ordered is likely the way we would do it. That's also the only solution with any chance of working by default with the way most decorators are structured (accepting *args and **kwargs and passing them to the wrapped function). To expand on Raymond's response in the previous thread on this topic, there are likely a number of steps to this process: 1. Provide a _collections.OrderedDict C implementation 2. Create a PEP to gain agreement from other implementations (especially IronPython, PyPy and Jython) to proceed with the remaining steps 3. Make it a builtin class (odict?) in its own right (with collections.OrderedDict becoming an alias for the builtin type) 4. Update the interpreter to use the new builtin type for kwargs containers Use various microbenchmarks to check that the use of the new odict builtin type instead of a plain dict doesn't slow things down too much. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Thu, Jan 20, 2011 at 6:05 AM, M.-A. Lemburg wrote:

Nick Coghlan wrote:

...

On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano wrote:

...

I would be +0 on making **kwargs an ordered dict automatically, and -1 on adding ***ordered_kwargs. Because kwargs is mostly used only for argument passing, and generally with only a small number of items, it probably doesn't matter too much if it's slightly slower than an unordered dict.

Yeah, simply making the kwargs dict always ordered is likely the way we would do it. That's also the only solution with any chance of working by default with the way most decorators are structured (accepting *args and **kwargs and passing them to the wrapped function).

-1.

How often do you really need this ?

In which of those cases wouldn't a static code analysis give you the call order of the parameters already  ?

"Nice to have" is not good enough to warrant a slow down of all function calls involving keyword arguments, adding overhead for other Python implementations and possibly causing problems with 3rd party extensions relying on getting a PyDict for the keyword arguments object.

What he says. In addition, I wonder what the semantics would be if the caller passed **d where d was an *unordered* dict... -- --Guido van Rossum (python.org/~guido)

On Thu, Jan 20, 2011 at 8:42 AM, Guido van Rossum wrote:

On Thu, Jan 20, 2011 at 6:05 AM, M.-A. Lemburg wrote:

...

Nick Coghlan wrote:

...

On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano wrote:

...

I would be +0 on making **kwargs an ordered dict automatically, and -1 on adding ***ordered_kwargs. Because kwargs is mostly used only for argument passing, and generally with only a small number of items, it probably doesn't matter too much if it's slightly slower than an unordered dict.

Yeah, simply making the kwargs dict always ordered is likely the way we would do it. That's also the only solution with any chance of working by default with the way most decorators are structured (accepting *args and **kwargs and passing them to the wrapped function).

-1.

How often do you really need this ?

In which of those cases wouldn't a static code analysis give you the call order of the parameters already  ?

"Nice to have" is not good enough to warrant a slow down of all function calls involving keyword arguments, adding overhead for other Python implementations and possibly causing problems with 3rd party extensions relying on getting a PyDict for the keyword arguments object.

What he says.

In addition, I wonder what the semantics would be if the caller passed **d where d was an *unordered* dict...

Wouldn't this be a good argument for the original proposal? That there wouldn't be confusion about whether you were getting an odict or a dict with ***? Also, would functions that didn't specify this behavior see an actual performance hit? I assumed that given the existence of METH_NOARGS and friends that there was some kind of optimization going on here, but I can't get it to turn up on timeit. Geremy Condra

On Thu, Jan 20, 2011 at 8:42 AM, Guido van Rossum wrote:

On Thu, Jan 20, 2011 at 6:05 AM, M.-A. Lemburg wrote:

...

"Nice to have" is not good enough to warrant a slow down of all function calls involving keyword arguments, adding overhead for other Python implementations and possibly causing problems with 3rd party extensions relying on getting a PyDict for the keyword arguments object.

What he says.

In addition, I wonder what the semantics would be if the caller passed **d where d was an *unordered* dict...

-- --Guido van Rossum (python.org/~guido)

Agree with both. And if we were to make this change, my next thought is that what I really want is an ordered multi-set, since in some scenarios where I want ordered parameters I also want repeated parameters. I don't think we should go there. Back to the original problem though: if the issue is that creating an ordered dict is clumsy and perhaps interfering with adoption and usage then perhaps the notation for ordered dict could be improved. Just as we can now use {...} for both dicts and sets, perhaps we could add [ 'b' : 1, 'a' : 2 ] as a more convenient way of writing OrderedDict([('b', 1), ('a', 2)]) This is parallel to the way that [1,2] is an ordered container while {1,2} is unordered. --- Bruce Latest blog post: http://www.vroospeak.com/2010/12/fix-filibuster.html Learn about security: http://j.mp/gruyere-security

On Thu, Jan 20, 2011 at 11:47 AM, Tim Delaney wrote:

['b':1] would then be ambiguous (appears to be a slice of a list). More obvious in the case of [1:2] ...

We use parenthesis for tuples and avoid the ambiguity by writing (1,). In the same way, we could require your examples to be written ['b':1,] and [1:2,] --- Bruce

On 20/01/2011 19:47, Tim Delaney wrote:

On 21 January 2011 06:13, Bruce Leban mailto:bruce@leapyear.org> wrote:

Back to the original problem though: if the issue is that creating an ordered dict is clumsy and perhaps interfering with adoption and usage then perhaps the notation for ordered dict could be improved. Just as we can now use {...} for both dicts and sets, perhaps we could add

[ 'b' : 1, 'a' : 2 ]

as a more convenient way of writing

OrderedDict([('b', 1), ('a', 2)])

This is parallel to the way that [1,2] is an ordered container while {1,2} is unordered.

['b':1] would then be ambiguous (appears to be a slice of a list). More obvious in the case of [1:2] ...

[snip] In what way is it ambiguous? [1] isn't ambiguous, is it? spam[1] is subscripting and [1] is a list; spam[1 : 2] is slicing and [1 : 2] would be an ordered dict.

On 2011-01-20, at 17:42 , Guido van Rossum wrote:

On Thu, Jan 20, 2011 at 6:05 AM, M.-A. Lemburg wrote:

...

Nick Coghlan wrote:

...

On Thu, Jan 20, 2011 at 8:28 PM, Steven D'Aprano wrote:

...

I would be +0 on making **kwargs an ordered dict automatically, and -1 on adding ***ordered_kwargs. Because kwargs is mostly used only for argument passing, and generally with only a small number of items, it probably doesn't matter too much if it's slightly slower than an unordered dict.

Yeah, simply making the kwargs dict always ordered is likely the way we would do it. That's also the only solution with any chance of working by default with the way most decorators are structured (accepting *args and **kwargs and passing them to the wrapped function).

-1.

How often do you really need this ?

In which of those cases wouldn't a static code analysis give you the call order of the parameters already ?

"Nice to have" is not good enough to warrant a slow down of all function calls involving keyword arguments, adding overhead for other Python implementations and possibly causing problems with 3rd party extensions relying on getting a PyDict for the keyword arguments object.

What he says.

In addition, I wonder what the semantics would be if the caller passed **d where d was an *unordered* dict… Create an ordereddict based on d's iteration order would seem logical (but order would keep conserved for kwargs passed in explicitly, so in `foo(a=some, b=other, c=stuff, **d)` where `d` is a `dict` a, b, c would be the first three keys and then the keys of d would be stuffed after that in whatever order happens).

Do Python 3's semantics allow for further kwargs after **kwargs?