Antoine Pitrou added the comment: > I thought about that originally, but there's only ever one object > graph for the process, and as soon as you break any one edge in that > graph you pretty much invalidate anything based on caching traversal > results.
Ah, I was forgetting that a ABC registration also affects the subclasses of the registered class, and the abstract parents of the ABC class. So it's a bit more annoying than it looked like. > So it's not really an implementation detail, it's a promise to provide > a unique token for the current state of the object graph that can be > used reliably for cache invalidation. Sounds fair. > A callback based system is actually *harder* to use, because you can't > simply ask the question "Is my cache still valid?" - you have to > register a callback that sets a flag, or something similar. Your > lookup code ends up being: Well, the point of a callback based system is for the callback to invalidate or recompute the cache *right now*, so you don't have to "check a flag" each time you do a lookup. It's a basic cost/benefit compromise: the callback system makes invalidations more expensive, but lookups cheapers. Besides, a callback-based system can be more future-proof than exposing the raw cache tags or tokens. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16832> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
