91–100 of 181 posts
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.
Earlier quoted context omitted.
I believe newer Python versions have at least deterministic iteration order (correct me if I'm wrong), while some previous ones had a non-deterministic one (non-deterministic between mutiple invocations of the interpreter). But there is also OrderedDict which iterates in assignment order.
No, you're right. I believe dict orders were made deterministic (by insertion order) in 3.6. Before that, it was undefined.
Starting in 2.7.3 and 3.3, the hashing algorithm applied a per-process random salt to certain built-in types, in order to mitigate a potential denial-of-service vector by crafting dictionary keys which cause hash collisions. Unless the PYTHONHASHSEED environment variable was set to a consistent value, iteration over a dictionary was no longer accidentally consistent across runs.
In 3.6, the dictionary implementation was rewritten to drastically improve performance. As a side effect, dictionary iteration became consistent again, this time determined by insertion order. In 3.6, this consistency was an implementation detail and not to be relied on.
Beginning with 3.7, dictionary iteration order is finally guaranteed by the language, independent of implementation, and goes by insertion order.
Earlier quoted context omitted.
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 ne…
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
It is surprising though that the order was non-deterministic, not only undefined. Determinism is something I intuitively expect from read-only operations like iteration.
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…
I have the opposite reaction to it, it seems insanely idiotic to have a associative array with ordered keys. It can only make sense to someone who doesn't know anything about fundamental data structures and a language that caters to people like that in spite of the performance penalty is just strange. but hey, its Guido, I still can't fathom that he moved reduce into functools.
the Path thing is incredible! I wasn't aware of it. I'll definitively be replacing my os.path.join calls for a more readable version of it.
> test_path = datasets_root / dataset / 'test' > Previously it was always tempting to use string concatenation (concise, but obviously bad), now with pathlib the code is safe, concise, and readable. This is the kind of feature that I'm wary to use even in scripts: questionable benefit, and probably too clever.
Earlier quoted context omitted.
I don't have a machine available right now, but I wonder what happens if two adjacent path elements are integers? Does it perform division instead of path/string concatenation?
The Path object won't construct a path from an integer. >>> from pathlib import Path >>> p=Path(1) Traceback (most recent call last): File " ", line 1, in File "/usr/lib/python3.6/pathlib.py", line 979, in __new__ self = cls._from_parts(args, init=False) File "/usr/lib/python3.6/pathlib.py", line 654, in _from_parts drv, root, parts = self._parse_args(args) File "/usr/lib/python3.6/pathlib.py", line 638, in _parse_ar…
Python is strongly typed.
Earlier quoted context omitted.
Dicts never had an iteration order, though. If you relied on dicts iterating in order, you were kind of asking for it.
There’s a well known YouTube video which covers all this comprehensively. Raymond Hettinger, Modern Python Dictionaries... hopefully this is the correct one. https://youtu.be/npw4s1QTmPg
Type hinting isn't part of Python 3, it's part of Python 3.5+.
The 'typing' module in the standard library was new as of 3.5.
Syntactic support for annotating variables was new as of 3.6.
Support for delaying resolution of annotations is new in 3.7 with a __future__ import.
Originally the annotation feature was seen as a possible way to add type hints to Python, but other potential uses were envisioned and no immediate preference was given to types over other uses of annotations.
the Path thing is incredible! I wasn't aware of it. I'll definitively be replacing my os.path.join calls for a more readable version of it.
Wow, I switched to Python 3 really early on and never knew about pathlib.
And collections.ChainMap.
And f-strings.
And yield from.
And type hints.
And statistics.
And ipadress.
And secrets.
And matmul.
And subprocess.run.
Come on, Python 3 is packed with awesomeness !