Dict view on list of two-tuples
It would be nice if the stdlib had a data structure that represented a dict view on a list of key/value tuples. This has come up a bit when thinking about common web request/response objects, as they all have an object like this but they all have slightly different APIs (and sometimes slightly different notions of what they want to do). For instance: d = multidict([('a', '1'), ('b', '2'), ('a', '3')]) There are some open questions: d['a'] -- '1' or '3'? d.items() -- could be [('a', '1'), ('b', '2'), ('a', '3')], or [('b', '2'), ('a', '3')] how do you get all values for 'a'? (e.g., d.getall('a') == ['1', '3']) what does "del d['a']" do? what does "d['a'] = '4'" do? It may overwrite or add a value. Both are valid -- how do you do the other. d.pop() etc need specifying. does d represent a view or a copy of the list? I.e., are updates to the list reflected in d? Some implementations only represent ordering of individual values, e.g., they'll show that '3' comes after '1'. But I need a complete ordering, that is, I need to know the key ordering is 'a', 'b', 'a' (it does not necessarily need to be shown through d.items(), but some method should expose this). Data structures with an internal representation like {'a': ['1', '3'], 'b': ['2']} are not sufficient. For reference, my own opinion of an implementation: https://bitbucket.org/ianb/webob/src/tip/webob/multidict.py#cl-13 Ian
Ian Bicking wrote:
I don't know whether "dict view" is the right terminology, but I've frequently found myself writing code that accepts a mapping, either a dict or a list of (key,value) items. So far I've handled this in an ad hoc way, only implementing as much functionality as I've needed at the time. I can't say it's been a major burden. Perhaps the simplest thing would be a key/value mapping (kvmap?) type that wraps such a list with a dict interface. Which parts of the dict interface (all of it? only some of it?) remains to be answered. For sure though, it would have to loosen the requirement that keys are unique and unsorted. (key,value) pairs are only useful for when you need non-unique, ordered keys, otherwise I'd just use a dict :)
Data structures with an internal representation like {'a': ['1', '3'], 'b': ['2']} are not sufficient.
How do you know? The ordered dict implementation in the standard library has an internal dict representation (or at least it did, when it was on ActiveState). Why do you care whether the implementation uses a dict internally, so long as the interface matches the specified (and as yet not entirely decided) API? -- Steven
On Mon, Apr 4, 2011 at 5:56 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Well, I can say at least that it would not be sufficient for me to use it in WebOb -- I wouldn't consider it acceptable to lose the full ordering of all keys, as would happen if you used this structure. It might be suitable for some other use, but I have no such use in mind at the moment, so diverging from this it would no longer be the idea that led me to start the thread ;) Ian
Ian Bicking wrote:
You have missed my point. What makes you think that using a dict as part of the *internal implementation* would mean that you lose the full ordering of keys? ordereddict has full ordering of keys, and it uses a dict as the internal implementation. The point is that you shouldn't declare what *implementation* a solution may or may not use, only the desired functionality. Functional requirements: *what* the code should do Implementation: *how* the code performs the required functions In my experience as a manager at an IT company, one of the hardest lessons for technical people to learn is not to mix implementation details in the functional requirements. That and not spending sixteen hours solving a problem when the customer has only authorised three :) You shouldn't rule out implementations based on preconceptions of what is or isn't possible. If somebody had declared "ordereddict must not use a dict under the hood", we wouldn't have an ordereddict in the standard library, or we'd have a sub-standard one. -- Steven
On Mon, Apr 4, 2011 at 7:14 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I was referring to the representation as a shorthand for what I considered a common but poor implementation of the concept -- *that specific* internal representation has specific results which I consider unacceptable (that is, it keeps the relative ordering of the values of one key, but doesn't keep the ordering between keys). Another representation that uses a dict could be fine, but I didn't offer a generic representation, I offered a specific one. Ian
On Mon, Apr 4, 2011 at 9:21 PM, Ian Bicking <ianb@colorstudy.com> wrote:
Nonetheless, I can't see as a "dict-view" for this data could replicate the full order - and be usable in the sense of using keys. I think that if one needs the full order as stated, the obvious way to consume that data is as a sequence of 2-tuples. On the other hand, I am +1 for a standardization of this, and for the implementation of a "dict-view" to an object that otherwise is a sequence of 2-tuples. js -><-
Ian Bicking wrote:
I don't know whether "dict view" is the right terminology, but I've frequently found myself writing code that accepts a mapping, either a dict or a list of (key,value) items. So far I've handled this in an ad hoc way, only implementing as much functionality as I've needed at the time. I can't say it's been a major burden. Perhaps the simplest thing would be a key/value mapping (kvmap?) type that wraps such a list with a dict interface. Which parts of the dict interface (all of it? only some of it?) remains to be answered. For sure though, it would have to loosen the requirement that keys are unique and unsorted. (key,value) pairs are only useful for when you need non-unique, ordered keys, otherwise I'd just use a dict :)
Data structures with an internal representation like {'a': ['1', '3'], 'b': ['2']} are not sufficient.
How do you know? The ordered dict implementation in the standard library has an internal dict representation (or at least it did, when it was on ActiveState). Why do you care whether the implementation uses a dict internally, so long as the interface matches the specified (and as yet not entirely decided) API? -- Steven
On Mon, Apr 4, 2011 at 5:56 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Well, I can say at least that it would not be sufficient for me to use it in WebOb -- I wouldn't consider it acceptable to lose the full ordering of all keys, as would happen if you used this structure. It might be suitable for some other use, but I have no such use in mind at the moment, so diverging from this it would no longer be the idea that led me to start the thread ;) Ian
Ian Bicking wrote:
You have missed my point. What makes you think that using a dict as part of the *internal implementation* would mean that you lose the full ordering of keys? ordereddict has full ordering of keys, and it uses a dict as the internal implementation. The point is that you shouldn't declare what *implementation* a solution may or may not use, only the desired functionality. Functional requirements: *what* the code should do Implementation: *how* the code performs the required functions In my experience as a manager at an IT company, one of the hardest lessons for technical people to learn is not to mix implementation details in the functional requirements. That and not spending sixteen hours solving a problem when the customer has only authorised three :) You shouldn't rule out implementations based on preconceptions of what is or isn't possible. If somebody had declared "ordereddict must not use a dict under the hood", we wouldn't have an ordereddict in the standard library, or we'd have a sub-standard one. -- Steven
On Mon, Apr 4, 2011 at 7:14 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I was referring to the representation as a shorthand for what I considered a common but poor implementation of the concept -- *that specific* internal representation has specific results which I consider unacceptable (that is, it keeps the relative ordering of the values of one key, but doesn't keep the ordering between keys). Another representation that uses a dict could be fine, but I didn't offer a generic representation, I offered a specific one. Ian
On Mon, Apr 4, 2011 at 9:21 PM, Ian Bicking <ianb@colorstudy.com> wrote:
Nonetheless, I can't see as a "dict-view" for this data could replicate the full order - and be usable in the sense of using keys. I think that if one needs the full order as stated, the obvious way to consume that data is as a sequence of 2-tuples. On the other hand, I am +1 for a standardization of this, and for the implementation of a "dict-view" to an object that otherwise is a sequence of 2-tuples. js -><-
participants (3)
-
Ian Bicking -
Joao S. O. Bueno -
Steven D'Aprano