> My perspective is biased towards correctness and “WTF are you doing?”
What an arrogant and pompous thing to say.
That tells everything you need to know, the author thinks of themselves as some sort of intellectual God.
Python 3.8 Makes me Sad Again
41–48 of 48 posts
Re: Python 3.8 Makes me Sad Again
#42There is some valid criticism but, as pointed out, fixing language inconsistencies when there is a corpus of programs already running is not trivial. Maybe when we decide to make Python 4. /me ducks
I would sure love it if the packaging folks could come to some conclusion.
The fragmented packaging scene is not a core language problem, but a real source of dismay nonetheless.
Re: Python 3.8 Makes me Sad Again
#43>This works because regular dicts have guaranteed ordering since Python 3.7
But the API is different! OrderedDict has more methods that have to do with order, and `reverse` works on its `.keys()` and `.values()`. Or did they fix this in 3.8?
Re: Python 3.8 Makes me Sad Again
#44Earlier quoted context omitted.
It is not as simple as that. It might looks "free" in this particular implementation, but it obviously prevents further optimizations.
To follow up on lightgreen's comment, in arijun's own linked-to URI they specifically mention the new level of indirection right away. Indirection is not "free" at all. For very large dict()s in main memory/DRAM it could be 2X slower. A hot loop benchmark where the CPU can perfectly predict its near future work and its prefetcher can mask DRAM latency may not reveal this, but a less "simple" benchmark would. The prim…
The reason for the change for more compact dicts. Thus the fact that it also preserved insertion order was a happy accident with no additional cost; what I called "free".
Re: Python 3.8 Makes me Sad Again
#45Earlier quoted context omitted.
Actually in this case I believe it did come for free due to a change in the way dict was implemented in 3.6: https://mail.python.org/pipermail/python-dev/2016-September/...
It is not as simple as that. It might looks "free" in this particular implementation, but it obviously prevents further optimizations.
You're right. If a more efficient but unordered dict were to come out, it would have to be in an import and have less comfortable syntax, since the base dict has a requirement for preserving insert order. But python is not C, and speed is not the most important consideration. Python often goes for "efficient enough, and very comfortable to use", for example by using lists as its ordered flat container instead of arrays. I think that making dicts ordered is another step in the right direction for Python.
Re: Python 3.8 Makes me Sad Again
#46There is some valid criticism but, as pointed out, fixing language inconsistencies when there is a corpus of programs already running is not trivial. Maybe when we decide to make Python 4. /me ducks
I would sure love it if the packaging folks could come to some conclusion. The fragmented packaging scene is not a core language problem, but a real source of dismay nonetheless.
As PyPI is not a curated repository, I don't see how that could be done.
Re: Python 3.8 Makes me Sad Again
#47Earlier quoted context omitted.
It is not as simple as that. It might looks "free" in this particular implementation, but it obviously prevents further optimizations.
You're right. If a more efficient but unordered dict were to come out, it would have to be in an import and have less comfortable syntax, since the base dict has a requirement for preserving insert order. But python is not C, and speed is not the most important consideration. Python often goes for "efficient enough, and very comfortable to use", for example by using lists as its ordered flat container instead of arra…
What Python calls "list" other languages call "array" (or "vector" or "seq" or "dynarray" or ...). So, it is not at all "instead of arrays" as you said, but rather "arrays by another name". People usually say "linked list" or "singly linked list" or "doubly linked list" to refer to the idea/data structure that does pointer hopping during traversal.
Re: Python 3.8 Makes me Sad Again
#48Earlier quoted context omitted.
You're right. If a more efficient but unordered dict were to come out, it would have to be in an import and have less comfortable syntax, since the base dict has a requirement for preserving insert order. But python is not C, and speed is not the most important consideration. Python often goes for "efficient enough, and very comfortable to use", for example by using lists as its ordered flat container instead of arra…
What Python calls "list" other languages call "array" (or "vector" or "seq" or "dynarray" or ...). So, it is not at all "instead of arrays" as you said, but rather "arrays by another name". People usually say "linked list" or "singly linked list" or "doubly linked list" to refer to the idea/data structure that does pointer hopping during traversal.
Most languages don’t have dynamically resizing arrays, so IMHO vec is a better fit. But my point wasn’t about the name. It was that if you don’t want to incur the costs associated with automatic resizing or with the indirection in python lists (as they are built as arrays of pointers), you have to use a different, less convenient library, like array or numpy. And that’s ok, considering the language goals.