371–380 of 457 posts
Earlier quoted context omitted.
If your code relies on a minimum python version, you can add `python_requires=">=3.5"` to your setup.py [ https://packaging.python.org/guides/distributing-packages-us... ] to ensure it's not installed on older releases. That field itself is kinda new; but if needing to block users with older versions, that shouldn't be an issue.
Python 3.4 is EOL anyway so there's no need to do this. Anybody running 3.4 is already unsupported.
Am I the only one that thinks this is a stupid decision? This will silently break code that starts to rely on this behaviour that gets executed on Python3.5 and lower. I would consider changing how a builtin works to be a major breaking change. It would have been fine if this was a change between 2 and 3 but on a minor version? Thats insane.
My main issue with it is that if someone figures out an even better way to do dictionaries but it doesn't preserve insertion order, then that technique can't be used. But I certainly wouldn't call it a stupid decision, the problem is that once a behaviour is observable then people absolutely will start relying on it.
It does come at a cost, but I think Python aims for ease of use over runtime speed and memory efficiency, so it seems perfect for them.
Earlier quoted context omitted.
> about a feature we had since Python 3.6, in 2016 No, you had that feature in one implementation. Now it's in the language specification. That's vastly different because only now you can rely on it without fearing it can go away with the next release.
First, cPython is 99% of Python deployments. So much that if a script works on it but not on another implementation, people often consider the later broken. As this post proves that most people don't even know about this feature, you can be pretty sure the vast majority of people don't know about pypy, micropython, etc. Secondly, even if you want to nit pick, Python 3.7 made it official more than one year ago. We are…
[0] Well, he usually gives great talks anyway
[1] Alright, he literally started many talks doing that
Earlier quoted context omitted.
Users of JSON, probably the most common data interchange format on the planet, frequently have implicit requirements about key ordering. It is highly convenient to be able to parse a JSON string into a native Python data structure, add a field, emit it back, and preserve the ordering.
in what reasonable use case would the order of the properties on an object matter? I can't think of one
[1] Well you _can_ choose to do so, and I recently have, but it's not without its costs.
I live in the Python bubble, so I haven't realized until this post that so few people knew about that. This post is massively popular despite talking about a feature we had since Python 3.6, in 2016, that was posted on HN at the time and that is featured in most popular tutorials. A good reminder that most of the world doesn't revolve about my favorite language. And that information is not that fast to spread.
I live in the Python bubble, so I haven't realized until this post that so few people knew about that. This post is massively popular despite talking about a feature we had since Python 3.6, in 2016, that was posted on HN at the time and that is featured in most popular tutorials. A good reminder that most of the world doesn't revolve about my favorite language. And that information is not that fast to spread.
I have lived in Python ~80% of my career (~50% now) currently), although a large chunk of my career was writing 2.7 compatible with 2.6 (thanks RHEL). For the last year and a half I have written 3.6+ exclusively and I didn't realize that regular dicts were now ordered. I don't use dicts if I require ordering, but if I did I would probably still reach for collections.OrderedDict... I wonder what the implications are o…
Earlier quoted context omitted.
From the docs: "CPython implementation detail: Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary’s history of insertions and deletions." So I would claim that equates to non-deterministic
I read that as: if two dicts are constructed in the same way and use the same python implementation then they'd be the same. If you change the way the dicts were generated or the underlying implementation then they're not the same. To me, nondeterministic is when the input does not change but the output does. The docs essentially say to not rely on the order, not that the result is not reproducible.
Earlier quoted context omitted.
What you describe is forward compatibility, and Python (and most other programming language) doesn't have it.
Usually languages don’t have it in a very explicit way though. If I try to use f-strings in python 3.5 I get a very explicit syntax error. If I rely on ordered insertions in Python3.5 I get a potentially difficult to diagnose bug.