Live data from Hacker News

Migrating to Python 3 with pleasure

github.com

71–80 of 181 posts

Re: Migrating to Python 3 with pleasure

#71
post #68
post #55

Earlier quoted context omitted.

why wouldn't you be able to just keep the same syntax and make it twice as fast in a newer implementation?

NIH. Personally I hate the new {} for set syntax. Is {} an empty set, or an empty dict?

An empty dict, for backward comptibility.

Re: Migrating to Python 3 with pleasure

#73
post #19

Earlier quoted context omitted.

CPython interates in this fashion since 3.6, but it is not part of the Python spec. Might be a bit contentious but it's not supposed to be relied upon

It was recently decided that as of 3.7 it will be. (Source: https://mail.python.org/pipermail/python-dev/2017-December/1... )

Hmmmmmm.... that makes it hard for other implementations. CPython isn't the whole of the Python world. Requirements like that can be problematic for implementations like Micropython, for instance.

Re: Migrating to Python 3 with pleasure

#74
post #43
post #14

Earlier quoted context omitted.

I have been conditioned to write code that is 2/3 compatible, that even when I am writing specifically for the PY3 interpreter the code turns out to be a __future__ import away from being valid PY2. I did not think much of them at first, but very recently, f-strings have changed that. I think many people get imprinted with writing the PY3 code using only the features available at the time they switched over.

You can use some backports of libraries though, surely? `pathlib` is in pip.

Back-ports are an option but they are an extra dependency. When you have not used a new feature, the cost of an extra dependency out weighs the unknown benefits that would be realised by using a back-port.

Re: Migrating to Python 3 with pleasure

#75

Earlier quoted context omitted.

Dicts are UNORDERED associative containers. If youre depending your app on implementation defined behavior, that's on your developpers shoulders. Stuff like that shouldn't pass code review

Not for much longer, as of 3.7 the ordering is a language feature: https://mail.python.org/pipermail/python-dev/2017-December/1... It's mad that it ever wasn't this way. Mapping-with-ordered-keys is such a useful and pervasive data structure (all database query result rows, for one) that an ordered dictionary should be a fundamental part of a language. It has been so much more pleasant to write python since ordering…

Ordereddict has been available for ages. Why should I pay for the overhead in the 98% of the cases where I don't need it.

Re: Migrating to Python 3 with pleasure

#76

I’m a little surprised at this point that Apple still doesn’t include a default Python 3.x on macOS. It’s the single thing keeping me from moving (as there’s a big difference between “just run this” and “first download this, then run this”).

There are arguments against doing anything against system python installs in the first place.

Re: Migrating to Python 3 with pleasure

#77

Earlier quoted context omitted.

It was recently decided that as of 3.7 it will be. (Source: https://mail.python.org/pipermail/python-dev/2017-December/1... )

Hmmmmmm.... that makes it hard for other implementations. CPython isn't the whole of the Python world. Requirements like that can be problematic for implementations like Micropython, for instance.

The entire reason they decided to make it a standard rather than keep it as an implementation detail is to make things better for users. It’s not about just looking after cpython.

Re: Migrating to Python 3 with pleasure

#78

Earlier quoted context omitted.

Not for much longer, as of 3.7 the ordering is a language feature: https://mail.python.org/pipermail/python-dev/2017-December/1... It's mad that it ever wasn't this way. Mapping-with-ordered-keys is such a useful and pervasive data structure (all database query result rows, for one) that an ordered dictionary should be a fundamental part of a language. It has been so much more pleasant to write python since ordering…

Ordereddict has been available for ages. Why should I pay for the overhead in the 98% of the cases where I don't need it.

Keeping the dict ordered is actually faster. There’s a link to a YouTube talk a little upthread that discusses the algorithms used. It’s really interesting.

Re: Migrating to Python 3 with pleasure

#79
post #64

Earlier quoted context omitted.

Not for much longer, as of 3.7 the ordering is a language feature: https://mail.python.org/pipermail/python-dev/2017-December/1... It's mad that it ever wasn't this way. Mapping-with-ordered-keys is such a useful and pervasive data structure (all database query result rows, for one) that an ordered dictionary should be a fundamental part of a language. It has been so much more pleasant to write python since ordering…

> Mapping-with-ordered-keys is such a useful and pervasive data structure (all database query result rows, for one) that an ordered dictionary should be a fundamental part of a language. Here's one real-life use case of that: Avro records. One of the formats Avro uses is a text format that's basically ordered JSON. One company I worked for years ago used Avro as its wire protocol, and some Avro data was stored as JSO…

Great example.

I hate to think of all the developer hours wasted because JSON doesn't maintain key ordering.

Re: Migrating to Python 3 with pleasure

#80

Earlier quoted context omitted.

Not for much longer, as of 3.7 the ordering is a language feature: https://mail.python.org/pipermail/python-dev/2017-December/1... It's mad that it ever wasn't this way. Mapping-with-ordered-keys is such a useful and pervasive data structure (all database query result rows, for one) that an ordered dictionary should be a fundamental part of a language. It has been so much more pleasant to write python since ordering…

Ordereddict has been available for ages. Why should I pay for the overhead in the 98% of the cases where I don't need it.

The new dict implementation was introduced in 3.5 (with forced order randomization, which was removed in 3.6) because it is faster and uses less memory than the previous non-ordered dict. Ordering is merely a nice byproduct. So you're not paying any penalty.

OrderedDict is fundamentally different because it is designed to allow inserting/removing keys in the middle of the ordering in O(1) time. It does not use the new dict under the hood, or vice-versa.

Post reply on HN