12 comments

[ 5.3 ms ] story [ 37.1 ms ] thread
I did exactly the same thing in our Confluence to XWiki migrator to easily and automatically report which macro parameters we don't handle when converting Confluence macros to equivalent macros in XWiki.

This can be used to evaluate the migration quality and spot what can be improved.

https://github.com/xwiki-contrib/confluence/blob/7a95bf96787...

I think if you feel like you need this then it's a bit of a red flag and you should be using Pydantic or `dataclass` instead, then your IDE can statically tell you which fields you don't access (among many other benefits). Dicts are mainly for when you don't know the keys up front.
Just a heads up, this fails to track usage of get and setdefault. The ability to iterate over dicts makes the whole question rather murky.
why not inside of __init__

  self.accessed_keys = set()
instead of

    @property
    def accessed_keys(self):
        return self._accessed_keys
I actually wrote something similar in nodejs for a data import system. Was very handy.
I have a similar use case and this idea also occurred to me.

However: the dict in this case would also include dataclasses, and I’d be interested in finding what exact attributes within those dataclasses were accessed, and also be able to mark all attributes in those dataclasses as accessed if the parent dataclasses is accessed, and with those dataclasses, being config objects, being able to do the same to its own children, so that the topmost dictionary has a tree of all accessed keys.

I couldn’t figure out how to do that, but welcome to ideas.

Only tangentially related but I am really excited about PEP 764¹ (inline typed dictionaries). If it gets accepted, we can finally replace entire hierarchies of dataclasses with simple nested dictionary types and call it a day.

I am currently teaching (typed) Python to a team of Windows sysadmins and it's been incredibly difficult to explain when to use a dataclass, a NamedTuple, a Pydantic model, or a dictionary.

¹) https://peps.python.org/pep-0764/

AI front: We have models to generate pictures, videos and code. We have the best devs and are so fskin rich!

Rust front: Here's a faster ls called ls-rs with different defaults, you should use this!

Go front: Here's reverse proxy #145728283 it is an open source project that has slightly different parameters than all the others.

Python hobo front: Uhh guys here's a dict that kinda might remember what you've accessed if you used it in a particular way.

For giant dicts a bloomfilter would work great here
Does this handle nested dicts (in pickles in sql, which I had to write code to survey one time)?

A queue-based traversal has flatter memory utilization for deeply nested dicts than a recursive traversal in Python without TCO.

Given a visitor pattern traversal, a visit() function can receive the node path as a list of path components, and update a Counter() with a (full,path,tuple) or "delimiter\.escaped.path" key.

Python collections.UserDict implements the methods necessary to proxy the dict Mapping/MutableMapping interface to self.data. For dicts with many keys, it would probably be faster to hook methods that mutate the UserDict.data dict like __setitem__, get, setdefault, update() and maybe __init__() in order to track which keys have changed instead of copying keys() into a set to do an unordered difference with a list.

React requires setState() for all mutations this.state because there's no way to hook dunder methods in JS: setState() updates this.state and then notifies listeners or calls a list of functions to run when anything in this.state or when a value associated with certain keys or nested keys in this.state changes.

FWIU ipyflow exposes the subscriber refcount/reflist but RxPy specifically does not: ipyflow/core/test/test_refcount.py: https://github.com/ipyflow/ipyflow/blob/master/core/test/tes...

Anyways,

For test assertions, unittest.mock MagicMock can track call_count and call_args_list on methods that mutate a dict like __getitem__ and get(). There's also mock_calls, which keeps an ordered list of the args passed: https://docs.python.org/3/library/unittest.mock.html