Change repr of collections.OrderedDict to be more dict-like
Hi, now when dicts are sorted, can we change the repr of collections.OrderedDict to look like dict? I mean from: OrderedDict([('a', '1'), ('b', '2')]) To: OrderedDict({'a': '1', 'b': '2'}) I assume the current list-of-tuples repr is there so copy pasting the repr to the interpreter results in the same OrderedDict. When dicts preserve insertion order, this now works with dict. I consider the dict-based repr much easier to read. Thoughts? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
I would wait a little bit. OrderedDict will probable become a pure synonym for dict, in a few releases, and the repr issue will solve itself, both giving the even simpler/nicer {'a': '1', 'b': '2'} Your proposal expose that dicts are ordered (which they are, but it's hidden). Once exposed, OrderedDict are obsolete and should be in the namespace only for backward compatibitlity. On Thursday, July 26, 2018 at 10:13:12 AM UTC+2, Miro Hrončok wrote:
On 26.7.2018 10:24, Grégory Lielens wrote:
I don't agree. See this thread: https://mail.python.org/pipermail/python-dev/2018-July/154765.html Namely: On 26.7.2018 05:23, INADA Naoki wrote:
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
True, I was not aware of that... But the thread also predict OrderedDict will become very unfrequent, and that's also my impression: we are currently removing our OrderedDict. I expect OrderedDict will be used only in place where the sequential order is a primary characteristic, with key access the secondary use pattern. dict will be used in the opposite context, key are the preffered access and order is only a secondary charateristic (that's our use case, order is needed only to make iteration order deterministic). In this sense, the current repr is imho better: it emphasize the order aspect (through the list) while your proposal emphasize the dict aspect.
On 7/26/2018 4:12 AM, Miro Hrončok wrote:
On python-idea, Miro Hrončok asked today whether we can change the OrderedDict repr from, for instance, OrderedDict([('a', '1'), ('b', '2')]) # to OrderedDict({'a': '1', 'b': '2'}) I am not sure what our repr change policy is, as there is a back-compatibility issue but I remember there being changes. -- Terry Jan Reedy
On 7/26/2018 1:23 PM, Terry Reedy wrote:
I posted on pydev thread [issue34221] Any plans to combine collections.OrderedDict with dict and Raymond Hettinger, collections author and maintainer, replied: We are allowed to change the repr in future versions of the language. Doing so does come at a cost though. There is a small performance penalty (see the timings below). Some doctests will break. And Python 3.8 printed output in books and blog posts would get shuffled if typed in to Python 3.5 -- this is problematic because one of the few remaining use cases for OrderedDict is to write code that is compatible with older Pythons. The proposed repr does look pretty but probably isn't worth the disruption. $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict([('a', '1'), ('b', '2')])" 200000 loops, best of 7: 1.12 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict({'a': '1', 'b': '2'})" 200000 loops, best of 7: 1.22 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict([('a', '1'), ('b', '2')])" 200000 loops, best of 7: 1.13 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict({'a': '1', 'b': '2'})" 200000 loops, best of 7: 1.2 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict([('a', '1'), ('b', '2')])" 200000 loops, best of 7: 1.12 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict({'a': '1', 'b': '2'})" 200000 loops, best of 7: 1.2 usec per loop -- Terry Jan Reedy
Sounds good to me. It'll make OrderedDict look much nicer at the REPL. On Thu, Jul 26, 2018 at 10:21 AM Terry Reedy <tjreedy@udel.edu> wrote:
I am not sure what our repr change policy is, as there is a back-compatibility issue but I remember there being changes.
Given the way different Python prompts feel free to change reprs, I always understood the repr to have no compatibility guarantees. On Thu, Jul 26, 2018 at 10:31 AM David Mertz <mertz@gnosis.cx> wrote:
Repr changes are likely to break doctests, at least. That's not necessarily an absolute "no", but it does raise the bar.
Breaking doctests is somewhat annoying, but I understand that to be more about verifying the accuracy of documentation than verifying the correctness of code. It's handy for following TDD, but that's during the initial development and a changed repr won't interfere.
On Thu, Jul 26, 2018 at 06:50:20PM -0400, David Mertz wrote:
I often use doctests to verify APIs and behaviors when I update code. I know I'm in a minority and most developers slightly disparage doctests.
I don't know why you think that "most developers" disparage doctests. Perhaps they're the same ones who think that "read the source" is all the documentation anyone needs. I know I don't. I love them. Tim Peters loves them (he should, he wrote the module) and if its good enough for Uncle Timmy then anyone who disparages them better have a damn good reason. Doc tests aren't perfect, but they fill a very important niche which is otherwise badly neglected by developers. I think we'd need to ask on Python-Dev to be sure, but my understanding is that backwards compatibility guarantees for reprs are weaker than those for regular APIs but stronger than those for error messages. Earlier, Michael Selik <mike@selik.org> wrote:
Given the way different Python prompts feel free to change reprs, I always understood the repr to have no compatibility guarantees.
That doesn't follow. The Python language makes no guarantees about how applications can display objects to the user, and a REPL is just another application. I suppose there might be an implied expectation that the official REPL that comes with the standard interpreter probably shouldn't make too many changes to the way things are displayed, but that's as far as it goes. [Michael (I think)]
Breaking doctests is more than "somewhat annoying", and you seem to have missed the point that the way we verify the accuracy of documentation is by verifying the correctness of code.
It's handy for following TDD, but that's during the initial development and a changed repr won't interfere.
I don't understand the reasoning here. Surely doctests are *less* valuable during initial development, when function APIs are in rapid change. (On the other hand, I use doctests to nail down what API I want, before I have an implementation.) Unless you delete all your documentation or stop running doctests when the project reaches the first stable version, I don't understand why you think that changing reprs won't interfere. -- Steve
Currently, what's the best way to implement a function f(OrderedDict([(1,2),(3,4)])) == '{1: 2, 3: 4}', works for all possible types, and also availaible for pprint with nice indent? If I could set a parameter in ipython or python repl that would print that, that would already be very useful. Le ven. 27 juil. 2018 à 07:23, Steven D'Aprano <steve@pearwood.info<mailto:steve@pearwood.info>> a écrit : On Thu, Jul 26, 2018 at 06:50:20PM -0400, David Mertz wrote:
I often use doctests to verify APIs and behaviors when I update code. I know I'm in a minority and most developers slightly disparage doctests.
I don't know why you think that "most developers" disparage doctests. Perhaps they're the same ones who think that "read the source" is all the documentation anyone needs. I know I don't. I love them. Tim Peters loves them (he should, he wrote the module) and if its good enough for Uncle Timmy then anyone who disparages them better have a damn good reason. Doc tests aren't perfect, but they fill a very important niche which is otherwise badly neglected by developers. I think we'd need to ask on Python-Dev to be sure, but my understanding is that backwards compatibility guarantees for reprs are weaker than those for regular APIs but stronger than those for error messages. Earlier, Michael Selik <mike@selik.org<mailto:mike@selik.org>> wrote:
Given the way different Python prompts feel free to change reprs, I always understood the repr to have no compatibility guarantees.
That doesn't follow. The Python language makes no guarantees about how applications can display objects to the user, and a REPL is just another application. I suppose there might be an implied expectation that the official REPL that comes with the standard interpreter probably shouldn't make too many changes to the way things are displayed, but that's as far as it goes. [Michael (I think)]
Breaking doctests is more than "somewhat annoying", and you seem to have missed the point that the way we verify the accuracy of documentation is by verifying the correctness of code.
It's handy for following TDD, but that's during the initial development and a changed repr won't interfere.
I don't understand the reasoning here. Surely doctests are *less* valuable during initial development, when function APIs are in rapid change. (On the other hand, I use doctests to nail down what API I want, before I have an implementation.) Unless you delete all your documentation or stop running doctests when the project reaches the first stable version, I don't understand why you think that changing reprs won't interfere. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Jul 27, 2018 at 05:30:35AM +0000, Robert Vanden Eynde wrote:
I don't understand the question, and I especially don't understand the "all possible types" part. Do you actually mean *all* possible types, like int, float, str, MyClassThatDoesSomethingWeird? But guessing (possibly incorrectly) what you want: py> from collections import OrderedDict py> od = OrderedDict([(1,2),(3,4)]) py> od == {1:2, 3: 4} True If efficiency is no concern, then the simplest way to get something that has a dict repr from an OrderedDict is to use a dict: py> dict(od) {1: 2, 3: 4} This also works as OrderedDict is a subclass of dict, and should avoid the cost of building an entire dict: py> dict.__repr__(od) '{1: 2, 3: 4}'
See sys.displayhook. -- Steve
Thanks for your response, I want to print/repr an OrderedDict() without relying on the fact that "dict are ordered" ie. I want a solution < python 3.7. Currently, if I do repr( OrderedDict([(1,2),(3,4)]) ), I get the string "OrderedDict([(1,2),(3,4)])", I'd like a function that would return the string "{1: 2, 3: 4}" in the correct order. If I do repr(dict( OrderedDict([(1,2),(3,4)]) )) I get "{1: 2, 3: 4}" because dict are ordered since python 3.7. And for pprint, currently pformat( OrderedDict([(1,2),(3,4)]) ) gives the string 'OrderedDict([(1, 2), (3, 4)])' (and adds \n for bigger dict). I could do pprint(dict( OrderedDict([(1,2),(3,4)]) )) but again that relies on python 3.7 behavior. I'm wondering if there exists an easy way to code this "order preserving repr and pprint/pformat". Le ven. 27 juil. 2018 à 07:58, Steven D'Aprano <steve@pearwood.info<mailto:steve@pearwood.info>> a écrit : On Fri, Jul 27, 2018 at 05:30:35AM +0000, Robert Vanden Eynde wrote:
I don't understand the question, and I especially don't understand the "all possible types" part. Do you actually mean *all* possible types, like int, float, str, MyClassThatDoesSomethingWeird? But guessing (possibly incorrectly) what you want: py> from collections import OrderedDict py> od = OrderedDict([(1,2),(3,4)]) py> od == {1:2, 3: 4} True If efficiency is no concern, then the simplest way to get something that has a dict repr from an OrderedDict is to use a dict: py> dict(od) {1: 2, 3: 4} This also works as OrderedDict is a subclass of dict, and should avoid the cost of building an entire dict: py> dict.__repr__(od) '{1: 2, 3: 4}'
See sys.displayhook. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Sorry Steven I didn't see your clever dict.__repr__ solution that Chris pointed out too. That's what I was looking for ^^ And now for pprint, apparently that doesn't seem difficult to implement. About the part where "the representation looses the type information", pformat(od) could be "OrderedDict{1:2, 3,4}" or "OrderedDict({1:2, 3:4})" but I don't ask for repr or pprint to change, just curious about how to implement that. </my_parenthesis> Le ven. 27 juil. 2018 à 11:53, Chris Angelico <rosuav@gmail.com> a écrit :
On Fri, Jul 27, 2018 at 9:24 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
Ah, fair point. Interestingly, the same problem hits repr(dict(od)), which I would have thought a reliable solution here. The simplest way that I've found is:
dict(od.items()) {'b': 2, 'a': 1}
That seems very odd. Iterating over the OD produces its keys in the correct order (b, a), but constructing a dict from it ignores iteration order and just goes "oh hey, this is a dict, we can snag that". Is that correct? ChrisA
27.07.18 16:29, Chris Angelico пише:
This looks like a bug to me. Opened https://bugs.python.org/issue34320 .
On Fri, Jul 27, 2018, 1:23 AM Steven D'Aprano <steve@pearwood.info> wrote:
I'm not talking about folks saying not to use tests at all. I've just read or heard a fair number of programmers say that doctests are not best practice, and using unittest or nose or something similar is more professional. It was an offhand content not a scientific poll. I'm delighted that you also use doctests, Steven. And if Timmy also does, I feel fully vindicated :-).
[David Mertz]
I often use doctests to verify APIs and behaviors when I update code. I
know I'm in a minority and most developers slightly disparage doctests.
[Steven D'Aprano]
Or ones who aren't happy unless they can demonstrate their mastery of a convoluted class hierarchy with hundreds of methods to memorize. Or unless they're Guido! He was never fond of doctest either. I know I don't. I love them. Tim Peters loves them (he should, he wrote
the module) and if its good enough for Uncle Timmy then anyone who disparages them better have a damn good reason.
Nope! They don't need any reason at all. I don't mind :-) It was a sneaky, although minor, purpose of doctest to raise the bar for making gratuitous changes to Python's output. Developers have approximately no appreciation for how off-putting it can be for users to struggle with docs showing output they don't actually see. Is the installation buggy? Did they type something wrong? Was the doc author just making stuff up? Etc. "Something's wrong here, but I don't know what" is not a happy experience :-( So I always count it as a Good Thing when someone points out "but doctests will break". _That_ developers can understand. It's a proxy for the real costs of making gratuitous changes, which are pretty much invisible to developers. Not that it should drive a decision - but it should be counted as _a_ cost. ... I think we'd need to ask on Python-Dev to be sure, but my understanding
is that backwards compatibility guarantees for reprs are weaker than those for regular APIs but stronger than those for error messages.
That sounds about right to me. The docs for doctest already point out that relying on reprs is dubious in various cases, so if someone is relying on the repr of OrderedDict in their doctests they presumably care about the repr more than the semantics. Or they were just confused ;-) In any case, since OrderedDict seems to be viewed as a legacy feature now, making any change to it is an odd idea on the face of it.
On 28.7.2018 07:27, Tim Peters wrote:
Note that there were coupl repr changes in 3.7 as well: repr for BaseException has changed to not include the trailing comma. Most exceptions are affected by this change. (Contributed by Serhiy Storchaka in bpo-30399.) repr for datetime.timedelta has changed to include the keyword arguments in the output. (Contributed by Utkarsh Upadhyay in bpo-30302.) https://docs.python.org/3.7/whatsnew/3.7.html#changes-in-the-python-api
In any case, since OrderedDict seems to be viewed as a legacy feature now, making any change to it is an odd idea on the face of it.
As far as I understood the discussions on python-dev, it is not viewed as legacy feature by everybody. At least when dicts with different order (otherwise the same) remain equal. I don't see that changing (it would be very backwards incompatible), hence I think OrderedDict still has it's place (far from legacy). https://mail.python.org/pipermail/python-dev/2018-July/154766.html -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
I would wait a little bit. OrderedDict will probable become a pure synonym for dict, in a few releases, and the repr issue will solve itself, both giving the even simpler/nicer {'a': '1', 'b': '2'} Your proposal expose that dicts are ordered (which they are, but it's hidden). Once exposed, OrderedDict are obsolete and should be in the namespace only for backward compatibitlity. On Thursday, July 26, 2018 at 10:13:12 AM UTC+2, Miro Hrončok wrote:
On 26.7.2018 10:24, Grégory Lielens wrote:
I don't agree. See this thread: https://mail.python.org/pipermail/python-dev/2018-July/154765.html Namely: On 26.7.2018 05:23, INADA Naoki wrote:
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
True, I was not aware of that... But the thread also predict OrderedDict will become very unfrequent, and that's also my impression: we are currently removing our OrderedDict. I expect OrderedDict will be used only in place where the sequential order is a primary characteristic, with key access the secondary use pattern. dict will be used in the opposite context, key are the preffered access and order is only a secondary charateristic (that's our use case, order is needed only to make iteration order deterministic). In this sense, the current repr is imho better: it emphasize the order aspect (through the list) while your proposal emphasize the dict aspect.
On 7/26/2018 4:12 AM, Miro Hrončok wrote:
On python-idea, Miro Hrončok asked today whether we can change the OrderedDict repr from, for instance, OrderedDict([('a', '1'), ('b', '2')]) # to OrderedDict({'a': '1', 'b': '2'}) I am not sure what our repr change policy is, as there is a back-compatibility issue but I remember there being changes. -- Terry Jan Reedy
On 7/26/2018 1:23 PM, Terry Reedy wrote:
I posted on pydev thread [issue34221] Any plans to combine collections.OrderedDict with dict and Raymond Hettinger, collections author and maintainer, replied: We are allowed to change the repr in future versions of the language. Doing so does come at a cost though. There is a small performance penalty (see the timings below). Some doctests will break. And Python 3.8 printed output in books and blog posts would get shuffled if typed in to Python 3.5 -- this is problematic because one of the few remaining use cases for OrderedDict is to write code that is compatible with older Pythons. The proposed repr does look pretty but probably isn't worth the disruption. $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict([('a', '1'), ('b', '2')])" 200000 loops, best of 7: 1.12 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict({'a': '1', 'b': '2'})" 200000 loops, best of 7: 1.22 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict([('a', '1'), ('b', '2')])" 200000 loops, best of 7: 1.13 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict({'a': '1', 'b': '2'})" 200000 loops, best of 7: 1.2 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict([('a', '1'), ('b', '2')])" 200000 loops, best of 7: 1.12 usec per loop $ python3.7 -m timeit -r 7 'from collections import OrderedDict' "OrderedDict({'a': '1', 'b': '2'})" 200000 loops, best of 7: 1.2 usec per loop -- Terry Jan Reedy
Sounds good to me. It'll make OrderedDict look much nicer at the REPL. On Thu, Jul 26, 2018 at 10:21 AM Terry Reedy <tjreedy@udel.edu> wrote:
I am not sure what our repr change policy is, as there is a back-compatibility issue but I remember there being changes.
Given the way different Python prompts feel free to change reprs, I always understood the repr to have no compatibility guarantees. On Thu, Jul 26, 2018 at 10:31 AM David Mertz <mertz@gnosis.cx> wrote:
Repr changes are likely to break doctests, at least. That's not necessarily an absolute "no", but it does raise the bar.
Breaking doctests is somewhat annoying, but I understand that to be more about verifying the accuracy of documentation than verifying the correctness of code. It's handy for following TDD, but that's during the initial development and a changed repr won't interfere.
On Thu, Jul 26, 2018 at 06:50:20PM -0400, David Mertz wrote:
I often use doctests to verify APIs and behaviors when I update code. I know I'm in a minority and most developers slightly disparage doctests.
I don't know why you think that "most developers" disparage doctests. Perhaps they're the same ones who think that "read the source" is all the documentation anyone needs. I know I don't. I love them. Tim Peters loves them (he should, he wrote the module) and if its good enough for Uncle Timmy then anyone who disparages them better have a damn good reason. Doc tests aren't perfect, but they fill a very important niche which is otherwise badly neglected by developers. I think we'd need to ask on Python-Dev to be sure, but my understanding is that backwards compatibility guarantees for reprs are weaker than those for regular APIs but stronger than those for error messages. Earlier, Michael Selik <mike@selik.org> wrote:
Given the way different Python prompts feel free to change reprs, I always understood the repr to have no compatibility guarantees.
That doesn't follow. The Python language makes no guarantees about how applications can display objects to the user, and a REPL is just another application. I suppose there might be an implied expectation that the official REPL that comes with the standard interpreter probably shouldn't make too many changes to the way things are displayed, but that's as far as it goes. [Michael (I think)]
Breaking doctests is more than "somewhat annoying", and you seem to have missed the point that the way we verify the accuracy of documentation is by verifying the correctness of code.
It's handy for following TDD, but that's during the initial development and a changed repr won't interfere.
I don't understand the reasoning here. Surely doctests are *less* valuable during initial development, when function APIs are in rapid change. (On the other hand, I use doctests to nail down what API I want, before I have an implementation.) Unless you delete all your documentation or stop running doctests when the project reaches the first stable version, I don't understand why you think that changing reprs won't interfere. -- Steve
Currently, what's the best way to implement a function f(OrderedDict([(1,2),(3,4)])) == '{1: 2, 3: 4}', works for all possible types, and also availaible for pprint with nice indent? If I could set a parameter in ipython or python repl that would print that, that would already be very useful. Le ven. 27 juil. 2018 à 07:23, Steven D'Aprano <steve@pearwood.info<mailto:steve@pearwood.info>> a écrit : On Thu, Jul 26, 2018 at 06:50:20PM -0400, David Mertz wrote:
I often use doctests to verify APIs and behaviors when I update code. I know I'm in a minority and most developers slightly disparage doctests.
I don't know why you think that "most developers" disparage doctests. Perhaps they're the same ones who think that "read the source" is all the documentation anyone needs. I know I don't. I love them. Tim Peters loves them (he should, he wrote the module) and if its good enough for Uncle Timmy then anyone who disparages them better have a damn good reason. Doc tests aren't perfect, but they fill a very important niche which is otherwise badly neglected by developers. I think we'd need to ask on Python-Dev to be sure, but my understanding is that backwards compatibility guarantees for reprs are weaker than those for regular APIs but stronger than those for error messages. Earlier, Michael Selik <mike@selik.org<mailto:mike@selik.org>> wrote:
Given the way different Python prompts feel free to change reprs, I always understood the repr to have no compatibility guarantees.
That doesn't follow. The Python language makes no guarantees about how applications can display objects to the user, and a REPL is just another application. I suppose there might be an implied expectation that the official REPL that comes with the standard interpreter probably shouldn't make too many changes to the way things are displayed, but that's as far as it goes. [Michael (I think)]
Breaking doctests is more than "somewhat annoying", and you seem to have missed the point that the way we verify the accuracy of documentation is by verifying the correctness of code.
It's handy for following TDD, but that's during the initial development and a changed repr won't interfere.
I don't understand the reasoning here. Surely doctests are *less* valuable during initial development, when function APIs are in rapid change. (On the other hand, I use doctests to nail down what API I want, before I have an implementation.) Unless you delete all your documentation or stop running doctests when the project reaches the first stable version, I don't understand why you think that changing reprs won't interfere. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Jul 27, 2018 at 05:30:35AM +0000, Robert Vanden Eynde wrote:
I don't understand the question, and I especially don't understand the "all possible types" part. Do you actually mean *all* possible types, like int, float, str, MyClassThatDoesSomethingWeird? But guessing (possibly incorrectly) what you want: py> from collections import OrderedDict py> od = OrderedDict([(1,2),(3,4)]) py> od == {1:2, 3: 4} True If efficiency is no concern, then the simplest way to get something that has a dict repr from an OrderedDict is to use a dict: py> dict(od) {1: 2, 3: 4} This also works as OrderedDict is a subclass of dict, and should avoid the cost of building an entire dict: py> dict.__repr__(od) '{1: 2, 3: 4}'
See sys.displayhook. -- Steve
Thanks for your response, I want to print/repr an OrderedDict() without relying on the fact that "dict are ordered" ie. I want a solution < python 3.7. Currently, if I do repr( OrderedDict([(1,2),(3,4)]) ), I get the string "OrderedDict([(1,2),(3,4)])", I'd like a function that would return the string "{1: 2, 3: 4}" in the correct order. If I do repr(dict( OrderedDict([(1,2),(3,4)]) )) I get "{1: 2, 3: 4}" because dict are ordered since python 3.7. And for pprint, currently pformat( OrderedDict([(1,2),(3,4)]) ) gives the string 'OrderedDict([(1, 2), (3, 4)])' (and adds \n for bigger dict). I could do pprint(dict( OrderedDict([(1,2),(3,4)]) )) but again that relies on python 3.7 behavior. I'm wondering if there exists an easy way to code this "order preserving repr and pprint/pformat". Le ven. 27 juil. 2018 à 07:58, Steven D'Aprano <steve@pearwood.info<mailto:steve@pearwood.info>> a écrit : On Fri, Jul 27, 2018 at 05:30:35AM +0000, Robert Vanden Eynde wrote:
I don't understand the question, and I especially don't understand the "all possible types" part. Do you actually mean *all* possible types, like int, float, str, MyClassThatDoesSomethingWeird? But guessing (possibly incorrectly) what you want: py> from collections import OrderedDict py> od = OrderedDict([(1,2),(3,4)]) py> od == {1:2, 3: 4} True If efficiency is no concern, then the simplest way to get something that has a dict repr from an OrderedDict is to use a dict: py> dict(od) {1: 2, 3: 4} This also works as OrderedDict is a subclass of dict, and should avoid the cost of building an entire dict: py> dict.__repr__(od) '{1: 2, 3: 4}'
See sys.displayhook. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Sorry Steven I didn't see your clever dict.__repr__ solution that Chris pointed out too. That's what I was looking for ^^ And now for pprint, apparently that doesn't seem difficult to implement. About the part where "the representation looses the type information", pformat(od) could be "OrderedDict{1:2, 3,4}" or "OrderedDict({1:2, 3:4})" but I don't ask for repr or pprint to change, just curious about how to implement that. </my_parenthesis> Le ven. 27 juil. 2018 à 11:53, Chris Angelico <rosuav@gmail.com> a écrit :
On Fri, Jul 27, 2018 at 9:24 PM, Serhiy Storchaka <storchaka@gmail.com> wrote:
Ah, fair point. Interestingly, the same problem hits repr(dict(od)), which I would have thought a reliable solution here. The simplest way that I've found is:
dict(od.items()) {'b': 2, 'a': 1}
That seems very odd. Iterating over the OD produces its keys in the correct order (b, a), but constructing a dict from it ignores iteration order and just goes "oh hey, this is a dict, we can snag that". Is that correct? ChrisA
27.07.18 16:29, Chris Angelico пише:
This looks like a bug to me. Opened https://bugs.python.org/issue34320 .
On Fri, Jul 27, 2018, 1:23 AM Steven D'Aprano <steve@pearwood.info> wrote:
I'm not talking about folks saying not to use tests at all. I've just read or heard a fair number of programmers say that doctests are not best practice, and using unittest or nose or something similar is more professional. It was an offhand content not a scientific poll. I'm delighted that you also use doctests, Steven. And if Timmy also does, I feel fully vindicated :-).
[David Mertz]
I often use doctests to verify APIs and behaviors when I update code. I
know I'm in a minority and most developers slightly disparage doctests.
[Steven D'Aprano]
Or ones who aren't happy unless they can demonstrate their mastery of a convoluted class hierarchy with hundreds of methods to memorize. Or unless they're Guido! He was never fond of doctest either. I know I don't. I love them. Tim Peters loves them (he should, he wrote
the module) and if its good enough for Uncle Timmy then anyone who disparages them better have a damn good reason.
Nope! They don't need any reason at all. I don't mind :-) It was a sneaky, although minor, purpose of doctest to raise the bar for making gratuitous changes to Python's output. Developers have approximately no appreciation for how off-putting it can be for users to struggle with docs showing output they don't actually see. Is the installation buggy? Did they type something wrong? Was the doc author just making stuff up? Etc. "Something's wrong here, but I don't know what" is not a happy experience :-( So I always count it as a Good Thing when someone points out "but doctests will break". _That_ developers can understand. It's a proxy for the real costs of making gratuitous changes, which are pretty much invisible to developers. Not that it should drive a decision - but it should be counted as _a_ cost. ... I think we'd need to ask on Python-Dev to be sure, but my understanding
is that backwards compatibility guarantees for reprs are weaker than those for regular APIs but stronger than those for error messages.
That sounds about right to me. The docs for doctest already point out that relying on reprs is dubious in various cases, so if someone is relying on the repr of OrderedDict in their doctests they presumably care about the repr more than the semantics. Or they were just confused ;-) In any case, since OrderedDict seems to be viewed as a legacy feature now, making any change to it is an odd idea on the face of it.
On 28.7.2018 07:27, Tim Peters wrote:
Note that there were coupl repr changes in 3.7 as well: repr for BaseException has changed to not include the trailing comma. Most exceptions are affected by this change. (Contributed by Serhiy Storchaka in bpo-30399.) repr for datetime.timedelta has changed to include the keyword arguments in the output. (Contributed by Utkarsh Upadhyay in bpo-30302.) https://docs.python.org/3.7/whatsnew/3.7.html#changes-in-the-python-api
In any case, since OrderedDict seems to be viewed as a legacy feature now, making any change to it is an odd idea on the face of it.
As far as I understood the discussions on python-dev, it is not viewed as legacy feature by everybody. At least when dicts with different order (otherwise the same) remain equal. I don't see that changing (it would be very backwards incompatible), hence I think OrderedDict still has it's place (far from legacy). https://mail.python.org/pipermail/python-dev/2018-July/154766.html -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
participants (13)
-
Chris Angelico -
David Mertz -
Eric V. Smith -
Grégory Lielens -
Michael Selik -
Miro Hrončok -
Robert Vanden Eynde -
Robert Vanden Eynde -
Serhiy Storchaka -
Steven D'Aprano -
Terry Reedy -
Thomas Jollans -
Tim Peters