
Hi, I was re-reading some old threads about ordereddict literals to see if any of them had gotten anywhere. Amongst them, I came across a post by Tim Delaney: https://mail.python.org/pipermail/python-ideas/2011-January/009049.html that mentioned an odict literal of ['key': 'value', 'key2': 'value2'] could be confused with slice notation.
from collections import OrderedDict class ODSlicer(object): def __getitem__(self, key): if type(key) is slice: key = [key] od = OrderedDict() for k in key: if type(k) is slice: od[k.start] = k.stop else: od[k] = k return od od = ODSlicer() print(od[1:2]) print(od["a":"b", "c":5]) print(od['a':'b', 'c':'d', ..., 'a':10, 'e':'f']) You could then replace: mydict = { 'foo': 'bar', 'baz': 'quux', } with: mydict = od[ 'foo': 'bar', 'baz': 'quux', ] if you need to convert a hardcoded dict into a hardcoded ordereddict. Works fine in python2.7 and python3.4. At this point, I'd like to note in my defence that this isn't called the python-good-ideas list :) What's the actual objection to supporting ['foo': 'bar'] odict literals? I saw Guido gave a -100, way back in the day, but no actual explanation for why it was distasteful? https://mail.python.org/pipermail/python-ideas/2009-June/004924.html Cheers, aj -- Anthony Towns <aj@erisian.com.au>

On Mar 18, 2014, at 17:54, Anthony Towns <aj@erisian.com.au> wrote:
I was re-reading some old threads about ordereddict literals to see if any of them had gotten anywhere.
Skimming the linked thread, there were a bunch of messages with variations of "It might be easier to judge if you came up with a real use case", but nobody ever did. So, do you have a real use case here? It might look better with headers from some protocol that need to be in order (except I can't think of any such protocol) or whatever you're hoping for than with examples like 'a' or 'foo' or 1.

On 19 March 2014 16:44, Andrew Barnert <abarnert@yahoo.com> wrote:
Oh, sure. The case that I've done most recently was when writing a tool to let me convert yaml files to and from jira issues. I want to specify how to convert each field between yaml and jira, and I also want to specify the order the fields end up in in the yaml file so that they're predictable. That's static information that I want to include in my source, and having it as a single ordereddict is the easiest way to write and store it. (The reason I want the ordering is both so that (a) if I dump an issue from jira to a file one day, and store it in git, then do it again the next day, the diff catches any intentional changes, not just random ordering changes, and (b) when I'm looking at the yaml file, the fields are in an order that makes sense to me so I know where to look for particular information). The code I ended up with was: class InterestingFields(OrderedDict): def __init__(self, extras): super(InterestingFields, self).__init__() D_key = D("key") D_name = D("name") s = S() t = T() f = self f["project"] = D_key f["issuetype"] = D_name f["summary"] = s # 18 more key/value pairs ... for k,v in extras: f[k] = v where D,S,T are classes that provide functions to convert from the Jira REST representation to the python version of the YAML representation I want and vice-versa. It took me a while to do the above in a way I didn't totally hate ("oh, I'll just do an OrderedDict( project=D_key, issuetype=D_name, ...)... huh, why didn't that work?"), and I can't say I *liked* what I ended up with. Better than specifying the fields twice (once for how to convert, once for the ordering), and better than all the heiroglyphics involved in writing it as a list of pairs though. The use case that was crossing my mind this morning was being able to write: return { "result": "ok", "details": "everything worked wonderfully" } from a function whose result gets turned into json and returned over a REST API, and have the order preserved so that when debugging with curl, I wouldn't see the "details" come first and confuse myself. Haven't decided how much I care about that yet. Cheers, aj -- Anthony Towns <aj@erisian.com.au>

On Mar 19, 2014, at 0:39, Anthony Towns <aj@erisian.com.au> wrote:
My first question is: why are you retrieving all 21 fields into named variables, and then putting them all into the dict? Why not just: f["project"] = D("key") Also, why does this have to be an OrderedDict in the first place? This isn't a collection of arbitrary fields where you want to preserve the order you found them in, it's primarily a collection of a fixed set of fields, which may have some extra fields at the end. In other words, an object. If the only issue is that you want to dump all your fields to YAML, you just need a reduce-type method that dumps them in the right order. You could do that in a variety of different ways; using an OrderedDict for your instance __dict__ is the obvious one, but your could also use a namedtuple instead of a normal class, use __slots__ (and store the extras in a single OrderedDict attribute), etc. If the problem is how to take the extras in a way that's nicer than an iterable of pairs so you don't need all those parens and brackets when you construct it, you can remove either the brackets or the parens or both by just using *extras at the end and taking the pairs as args, or taking the keys and values as alternating args. I don't mean to nitpick here, but I suspect this is exactly the kind of thing people were expecting--use cases that do unpythonic things like blur the line between objects and dicts ala JavaScript. Of course when you're dealing in JSON, or to some extent YAML, it's hard to completely avoid that blurring, but blurring it even farther isn't the solution.

It doesn't feel to me like the existing (non-literal) spelling is particularly bad:
So sure, you can't use the kw=val style of initialization, but the "list of pairs" style works fine. It's not that much longer than a literal would be. On Tue, Mar 18, 2014 at 5:54 PM, Anthony Towns <aj@erisian.com.au> wrote:
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

On Wed, Mar 19, 2014 at 2:00 AM, David Mertz <mertz@gnosis.cx> wrote:
FYI I'm working on a proposal to support preserving the call order of **kwargs. This would allow initializing an OrderedDict correctly using keyword args. I may have something to show for it by the end of the PyCon sprints. -eric

On Wed, Mar 19, 2014, at 17:24, Eric Snow wrote:
I know that it's possible to support this* in dict, but is kwargs required to be a dict? What route are you going: modify dict to allow this and require dict to support it; make a new class for kwargs and require this behavior of kwargs; modify dict on CPython to allow it but only require that kwargs support it "somehow" on non-CPython? *where "this" is e.g. "preservation of original insertion order for iterating when there have been no deletions"

Hello, Currently expression (a=1, b=2) is a syntax error. If it's defined to mean (('a',1), ('b',2)) it can be used when making OrderedDict or anything that requires named ordered args e.g. OrderedDict((a=1, b=2)) another variant with more changes in VM is OrderedDict(**(a=1, b=2)) Niki

On Mar 18, 2014, at 17:54, Anthony Towns <aj@erisian.com.au> wrote:
I was re-reading some old threads about ordereddict literals to see if any of them had gotten anywhere.
Skimming the linked thread, there were a bunch of messages with variations of "It might be easier to judge if you came up with a real use case", but nobody ever did. So, do you have a real use case here? It might look better with headers from some protocol that need to be in order (except I can't think of any such protocol) or whatever you're hoping for than with examples like 'a' or 'foo' or 1.

On 19 March 2014 16:44, Andrew Barnert <abarnert@yahoo.com> wrote:
Oh, sure. The case that I've done most recently was when writing a tool to let me convert yaml files to and from jira issues. I want to specify how to convert each field between yaml and jira, and I also want to specify the order the fields end up in in the yaml file so that they're predictable. That's static information that I want to include in my source, and having it as a single ordereddict is the easiest way to write and store it. (The reason I want the ordering is both so that (a) if I dump an issue from jira to a file one day, and store it in git, then do it again the next day, the diff catches any intentional changes, not just random ordering changes, and (b) when I'm looking at the yaml file, the fields are in an order that makes sense to me so I know where to look for particular information). The code I ended up with was: class InterestingFields(OrderedDict): def __init__(self, extras): super(InterestingFields, self).__init__() D_key = D("key") D_name = D("name") s = S() t = T() f = self f["project"] = D_key f["issuetype"] = D_name f["summary"] = s # 18 more key/value pairs ... for k,v in extras: f[k] = v where D,S,T are classes that provide functions to convert from the Jira REST representation to the python version of the YAML representation I want and vice-versa. It took me a while to do the above in a way I didn't totally hate ("oh, I'll just do an OrderedDict( project=D_key, issuetype=D_name, ...)... huh, why didn't that work?"), and I can't say I *liked* what I ended up with. Better than specifying the fields twice (once for how to convert, once for the ordering), and better than all the heiroglyphics involved in writing it as a list of pairs though. The use case that was crossing my mind this morning was being able to write: return { "result": "ok", "details": "everything worked wonderfully" } from a function whose result gets turned into json and returned over a REST API, and have the order preserved so that when debugging with curl, I wouldn't see the "details" come first and confuse myself. Haven't decided how much I care about that yet. Cheers, aj -- Anthony Towns <aj@erisian.com.au>

On Mar 19, 2014, at 0:39, Anthony Towns <aj@erisian.com.au> wrote:
My first question is: why are you retrieving all 21 fields into named variables, and then putting them all into the dict? Why not just: f["project"] = D("key") Also, why does this have to be an OrderedDict in the first place? This isn't a collection of arbitrary fields where you want to preserve the order you found them in, it's primarily a collection of a fixed set of fields, which may have some extra fields at the end. In other words, an object. If the only issue is that you want to dump all your fields to YAML, you just need a reduce-type method that dumps them in the right order. You could do that in a variety of different ways; using an OrderedDict for your instance __dict__ is the obvious one, but your could also use a namedtuple instead of a normal class, use __slots__ (and store the extras in a single OrderedDict attribute), etc. If the problem is how to take the extras in a way that's nicer than an iterable of pairs so you don't need all those parens and brackets when you construct it, you can remove either the brackets or the parens or both by just using *extras at the end and taking the pairs as args, or taking the keys and values as alternating args. I don't mean to nitpick here, but I suspect this is exactly the kind of thing people were expecting--use cases that do unpythonic things like blur the line between objects and dicts ala JavaScript. Of course when you're dealing in JSON, or to some extent YAML, it's hard to completely avoid that blurring, but blurring it even farther isn't the solution.

It doesn't feel to me like the existing (non-literal) spelling is particularly bad:
So sure, you can't use the kw=val style of initialization, but the "list of pairs" style works fine. It's not that much longer than a literal would be. On Tue, Mar 18, 2014 at 5:54 PM, Anthony Towns <aj@erisian.com.au> wrote:
-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

On Wed, Mar 19, 2014 at 2:00 AM, David Mertz <mertz@gnosis.cx> wrote:
FYI I'm working on a proposal to support preserving the call order of **kwargs. This would allow initializing an OrderedDict correctly using keyword args. I may have something to show for it by the end of the PyCon sprints. -eric

On Wed, Mar 19, 2014, at 17:24, Eric Snow wrote:
I know that it's possible to support this* in dict, but is kwargs required to be a dict? What route are you going: modify dict to allow this and require dict to support it; make a new class for kwargs and require this behavior of kwargs; modify dict on CPython to allow it but only require that kwargs support it "somehow" on non-CPython? *where "this" is e.g. "preservation of original insertion order for iterating when there have been no deletions"

Hello, Currently expression (a=1, b=2) is a syntax error. If it's defined to mean (('a',1), ('b',2)) it can be used when making OrderedDict or anything that requires named ordered args e.g. OrderedDict((a=1, b=2)) another variant with more changes in VM is OrderedDict(**(a=1, b=2)) Niki
participants (6)
-
Andrew Barnert
-
Anthony Towns
-
David Mertz
-
Eric Snow
-
Niki Spahiev
-
random832@fastmail.us