[Python-Dev] Guarantee ordered dict literals in v3.7? (original) (raw)

David Mertz mertz at gnosis.cx
Mon Nov 6 23:05:07 EST 2017

I strongly opposed adding an ordered guarantee to regular dicts. If the implementation happens to keep that, great. Maybe OrderedDict can be rewritten to use the dict implementation. But the evidence that all implementations will always be fine with this restraint feels poor, and we have a perfectly good explicit OrderedDict for those who want that.

On Nov 6, 2017 7:39 PM, "Brett Cannon" <brett at python.org> wrote:

On Mon, 6 Nov 2017 at 11:08 Paul Sokolovsky <pmiscml at gmail.com> wrote: Hello,

On Mon, 06 Nov 2017 17:58:47 +0000 Brett Cannon <brett at python.org> wrote: [] > > Why suddenly once in 25 years there's a need to do something to > > dict's, violating computer science background behind them (one of > > the reason enough people loved Python comparing to other "practical > > hack" languages)? > > I don't understand what "computer science background" is being > violated? I tried to explain that in the previous mail, can try a different angle. So, please open you favorite CS book (better few) and look up "abstract data types", then "mapping/associative array" and "list". We can use Wikipedia too: https://en.wikipedia.org/wiki/Associativearray. So, please look up: "Operations associated with this data type allow". And you'll see, that there're no "ordering" related operations are defined. Vice versa, looking at "sequence" operations, there will be "prev/next", maybe "get n'th" element operations, implying ordering. I don't think you meant for this to come off as insulting, but telling me how to look up the definition of an associative array or map feels like you're putting me down. I also have a Ph.D. in computer science so I'm aware of the academic definitions of these data structures.

Python used to be a perfect application of these principles. Its dict was a perfect CS implementation of an abstract associative array, and list - of "sequence" abstract type (with additional guarantee of O(1) random element access). People knew and rejoiced that Python is built on solid science principles, or could learn them from it. That no longer will be true, with a sound concept being replaced with on-the-spot practical hack, choosing properties of a random associative array algorithm implementation over properties of a superset of such algorithms (many of which are again don't offer any orderness guarantees). I don't think it's fair to call the current dict implementation a hack. It's a sound design that has a certain property that we are discussing the masking of. As I said previously, I think this discussion comes down to whether we think there are pragmatic benefits to exposing the ordered aspects to the general developer versus not. -Brett

I know though what will be replied (based on the replies below): "all these are implementation details" - no, orderness vs non-orderness of a mapping algorithm is an implementation detail; "users shouldn't know all that" - they should, that's the real knowledge, and up until now, they could learn that from Python docs, "we can't predict future" - we don't need, we just need to know the past (25 years in our case), and understand why it was done like that, I don't think Guido couldn't code it ordered in 1991, it's just not natural for a mapping type to be so, and in 2017, it's not more natural than it was in 1991. MicroPython in particular appeared because Python offered all the CS-sound properties and freedom and alternative choices for implementation (more so than any other scripting language). It's losing it, and not just for MicroPython's surprise. [] -- Best regards, Paul mailto:pmiscml at gmail.com

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ mertz%40gnosis.cx -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171106/cdfbb599/attachment.html>

More information about the Python-Dev mailing list