12 comments

[ 3.8 ms ] story [ 41.4 ms ] thread
I like that the author starts with a use-case and then solves it by using the class that the article sets out to introduce.

I do feel like the article lacks depth in describing what a chainmap actually is, how I can be sure which key takes precedence and lastly, I am not quite sure if I am convinced if the method for sanity checking values scales very well.

Also to add: do people still use "isinstance" for comparing types? Always has help like an antipattern to me.
How so? Do you mean because it is implicit in it's information rather than explicit?

I've been using it a bit for tree structures where an element could be a tree or a leaf, so isintance(node, tuple) is just the ticket. Seems simpler than creating a Node class, and can easily be dumped to json where I need

I do, if you do something like type(x) == SomeClass then you won't catch any subclasses of SomeClass
This is not a well written article. The Python documentation (https://docs.python.org/3/library/collections.html#collectio...) is clearer.

TLDR from the docs: ChainMap groups multiple dicts or other mappings together to create a single, updateable view.

> It is often much faster than creating a new dictionary and running multiple update() calls.

This is the important detail. This is much faster than how you'd solve it pre-3.3.

I found myself wondering why this required a new class in the stdlib until that line.

It would be nicer if Python just optimized the old way.
Semantically they’re not the same. In the ‘old way’ adding a key to one of the original dicts does not change the new dict. Whereas the new key will appear in the ChainMap.
The author mentions right at the top of the blog that they are going through a tough time, and they put substantially more effort into this post than you did with your comment.

> Be kind.

Chainmap is nifty for implementing lexical scope in interpreters
Thanks for the comments. The Author here. I know the article does indeed lack depth. But on the other hand, I have a precise goal in all the articles I write for this newsletter. I just want to introduce some concepts, which are not commonplace, very briefly. so that you can read in an email, in 2-3 minutes max. I try most of the time to point out to the original documentation so that anyone curious to know more can follow and learn the details.

What do you think about this approach?

(That is kind of why I named the newsletter as `Python's Byte` :) )

Wow! How did I miss this structure in Python in all the years I've worked with Python? Oh. I remember. Because it took so long for me move from Python 2 to Python 3. So I'm catching up.

Anyway, I enjoyed this article mostly because it jumped right into what it was for. It often takes articles just like this one to alert folks like me to one of the more interesting tools the language has to offer. I happen to have a number of projects I have to make changes to that might benefit from this structure. So kudos!