On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote:

The main use case seems to be the OrderedDict constructor itself. Otherwise, I can't think of any situation where I would've wanted it.

I've had a couple related to populating other mappings where order matters, at least from a predictability and readability perspective, even if it's not strictly required from a standards compliance point of view (think writing XML attributes, etc). I quite liked the idea of a simple flag attribute on function objects that the interpreter checked, with a decorator in functools (or even the builtins) to set it. It's not a particularly elegant solution, but it would get the job done with minimal performance impact on existing functions. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 19 May 2013 11:57, Guido van Rossum wrote:

Hm. Wouldn'tvevery call site be slowed down by checking for that flag?

Actually, when I was thinking on the subject I came to the same idea, of having some functions marked differently so they would use a different call mechanism - but them I wondered around having a different opcode for the ordered-dict calls. Would that be feasible? js -><-

— Sent from Mailbox

On Sun, May 19, 2013 at 7:42 AM, Nick Coghlan wrote:

...

On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote:

...

The main use case seems to be the OrderedDict constructor itself. Otherwise, I can't think of any situation where I would've wanted it.

I've had a couple related to populating other mappings where order matters, at least from a predictability and readability perspective, even if it's not strictly required from a standards compliance point of view (think writing XML attributes, etc).

I quite liked the idea of a simple flag attribute on function objects that the interpreter checked, with a decorator in functools (or even the builtins) to set it. It's not a particularly elegant solution, but it would get the job done with minimal performance impact on existing functions.

Cheers, Nick.

-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/jsbueno%40python.org.br

On Mon, May 20, 2013 at 11:35 AM, Greg Ewing wrote:

Joao S. O. Bueno wrote:

...

Actually, when I was thinking on the subject I came to the same idea, of having some functions marked differently so they would use a different call mechanism - but them I wondered around having a different opcode for the ordered-dict calls.

Would that be feasible?

No, because the callee is the only one that knows whether it requires its keyword args to be ordered.

In fact, not even the callee might know at the time of the call. Consider a function that takes **kwds and passes them on to another function that requires ordered keywords.

I wouldn't be bothered by that case, as it's no different from any other means of stuffing a dictionary through **kwds. If you want to preserve order through a wrapper, the wrapper needs to be declared to preserve order. The trouble is that there can't be any compile-time lookup to determine what (type of) function will be called, ergo this can't be resolved with a unique bytecode based on the destination. How big a deal would it be to bless OrderedDict with a special literal notation? Something like: od = o{'a': 1, 'b': 2, 'c': 3} Much of the need for ordered kwargs is for constructing OrderedDict itself after all (cf Antoine). ChrisA

On Sun, May 19, 2013 at 4:40 PM, Nick Coghlan wrote:

On Sun, May 19, 2013 at 11:01 PM, Antoine Pitrou wrote:

...

The main use case seems to be the OrderedDict constructor itself. Otherwise, I can't think of any situation where I would've wanted it.

I've had a couple related to populating other mappings where order matters, at least from a predictability and readability perspective, even if it's not strictly required from a standards compliance point of view (think writing XML attributes, etc).

I quite liked the idea of a simple flag attribute on function objects that the interpreter checked, with a decorator in functools (or even the builtins) to set it. It's not a particularly elegant solution, but it would get the job done with minimal performance impact on existing functions.

Cheers, Nick.

Note that raymonds proposal would make dicts and ordereddicts almost exactly the same speed.

On May 20, 2013, at 02:30 PM, Armin Rigo wrote:

Just checking: in view of Raymond's proposal, is there a good reason against having all dicts be systematically ordered? It would definitely improve the debugging experience, by making multiple runs of the same program more like each other, instead of depending on the random address-based ordering. (Performance-wise, I guess it might be a little bit slower or faster depending on cache issues and so on, but the emphasis I'd put is on the "little bit".)

I'm ambivalent on the proposal -- I could get behind it if it was demonstrably *not* a performance hit (I'm already fighting enough "Python is too slow" battles). However, if such a change were made, I think it must be adopted as a change to the language specification. Meaning, if dicts (or even just keyword arguments) are to be ordered, it can't be as a side-effect of the implementation. We've had a lot of churn getting code and tests to the point where most libraries have adjusted to the undefined order of dictionary iteration. I don't want to go back to the situation where lots of implicit ordering assumptions caused broken code when run in one implementation or another. Or in other words, if dicts are to be ordered, let's make it an explicit language feature that we can measure compliance against. -Barry

I think that kills the "let's make all dicts ordered" idea, even for CPython. I wouldn't want people to start relying on this. The dict type should be clearly recognizable as the hash table it is. Making **kwds ordered is still open, but requires careful design and implementation to avoid slowing down function calls that don't benefit. --Guido van Rossum (sent from Android phone) On May 20, 2013 8:25 AM, "fwierzbicki@gmail.com" wrote:

...

Or in other words, if dicts are to be ordered, let's make it an explicit language feature that we can measure compliance against. Guaranteeing a dict order would be tough on Jython - today it's nice

On Mon, May 20, 2013 at 6:39 AM, Barry Warsaw wrote: that we can just have a thin wrapper around ConcurrentHashMap. In a world with hard ordering guarantees I think we'd need to write our own from scratch.

-Frank _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

On 06/09/2013 10:13 PM, Alexander Belopolsky wrote:

On Sun, May 19, 2013 at 1:47 AM, Guido van Rossum mailto:guido@python.org> wrote:

I'm slow at warming up to the idea. My main concern is speed -- since most code doesn't need it and function calls are already slow (and obviously very common :-) it would be a shame if this slowed down function calls that don't need it noticeably.

And we could remove this bit from the docs... """ The OrderedDict constructor and update() method both accept keyword arguments, but their order is lost because Python’s function call semantics pass-in keyword arguments using a regular unordered dictionary. """

Here is an idea that will not affect functions that don't need to know the order of keywords: a special __kworder__ local variable. The use of this variable inside the function will signal compiler to generate additional bytecode to copy keyword names from the stack to a tuple and save it in __kworder__.

I like the idea of an ordered dict acting the same as a regular dict with an optional way to access order. It also will catch uses of unordered dicts in situations where an ordered dict is expected by having the ordered key words accessed in a way that isn't available in unordered dicts. I don't care for a magic local variable inside of a function.

With that feature, an OrderedDict constructor, for example can be written as

def odict(**kwargs): return OrderedDict([(key, kwargs[key]) for key in __kworder__])

There is two situations where this would matter... The packing of arguments when **kwargs is used in the function definition, and the unpacking of arguments when **kwargs is used in the function call. By having the unpackng side also work with ordered dicts, maybe we could then replace the many *very common* occurrences of (*args, **kwargs) with just (**all_args) or (***all_args). :) It's the unordered nature of dictionaries that requires *args to be used along with **kwargs when forwarding function arguments to other functions. Another variation of this is to have a way to forward a functions "signature name space" to another function directly and bypass the signature parsing those cases. Cheers, Ron