[issue16832] Expose cache validity checking support in ABCMeta

R. David Murray added the comment: I don't see that there's anything other than the doc change that needs done here, so I'm closing this. -- nosy: +r.david.murray resolution: -> fixed stage: -> committed/rejected status: open -> closed type: -> enhancement __

[issue16832] Expose cache validity checking support in ABCMeta

Roundup Robot added the comment: New changeset a9f73b44ea0e by R David Murray in branch 'default': #16832: s/integer/object/ in docs/docstring, and add whatsnew entry. http://hg.python.org/cpython/rev/a9f73b44ea0e -- ___ Python tracker

[issue16832] Expose cache validity checking support in ABCMeta

Nick Coghlan added the comment: The latter is probably better (it should just need a slight tweak to the wording in the docs and docstring) -- ___ Python tracker ___

[issue16832] Expose cache validity checking support in ABCMeta

Éric Araujo added the comment: About future-proofing: do we want to document that the token is an opaque integer (as is done now) or just an opaque object that supports equality comparisons? -- nosy: +eric.araujo ___ Python tracker

[issue16832] Expose cache validity checking support in ABCMeta

Nick Coghlan added the comment: The reason I switched from suggesting an attribute/property to a module level function is because we don't really support properties for process global state. That's why sys has so many getters in it - to make them properties, you would have to add a class objec

[issue16832] Expose cache validity checking support in ABCMeta

Antoine Pitrou added the comment: > This doesn't make any sense. Once you've exposed an API that gives > out a value for this, you can't change the implementation in a way > that doesn't involve handing out a value... in which case you can just > as easily set it as an attribute. Because it may

[issue16832] Expose cache validity checking support in ABCMeta

Phillip J. Eby added the comment: All that being said, I took out some time to get actual numbers, and found my original guesstimate of overhead was incorrect; it's only 3 times slower, not "orders of magnitude". ;-) And even on a relatively old machine, that 3 times slower amounts to an extra

[issue16832] Expose cache validity checking support in ABCMeta

Phillip J. Eby added the comment: Antoine Pitrou added the comment: > -1. Exposing a function allows to modify the underlying implementation > without breaking any API. This doesn't make any sense. Once you've exposed an API that gives out a value for this, you can't change the implementation i

[issue16832] Expose cache validity checking support in ABCMeta

Nick Coghlan added the comment: Trading correctness for speed is almost never a good idea. If people are worried about speed to that level, they can either bypass the public API and access the private attribute directly (after profiling their application to ensure the cache validity checks are

[issue16832] Expose cache validity checking support in ABCMeta

Antoine Pitrou added the comment: > Please expose this as an attribute of the class or module, not as a > function. A function is orders of magnitude slower than attribute > access, and the entire point of exposing this is to allow caches to be > invalidated. -1. Exposing a function allows to m

[issue16832] Expose cache validity checking support in ABCMeta

Phillip J. Eby added the comment: Please expose this as an attribute of the class or module, not as a function. A function is orders of magnitude slower than attribute access, and the entire point of exposing this is to allow caches to be invalidated. In order to be useful for cache invalidat

[issue16832] Expose cache validity checking support in ABCMeta

Roundup Robot added the comment: New changeset d9828c438889 by Łukasz Langa in branch 'default': Mention issue #16832 in Misc/NEWS http://hg.python.org/cpython/rev/d9828c438889 -- ___ Python tracker ___

[issue16832] Expose cache validity checking support in ABCMeta

Roundup Robot added the comment: New changeset 5b17d5ca2ff1 by Łukasz Langa in branch 'default': Fix #16832 - expose cache validity checking support in ABCMeta http://hg.python.org/cpython/rev/5b17d5ca2ff1 -- nosy: +python-dev ___ Python tracker

[issue16832] Expose cache validity checking support in ABCMeta

Łukasz Langa added the comment: Review the patch, please. Committing in 10... 9... 8... -- ___ Python tracker ___ ___ Python-bugs-list

[issue16832] Expose cache validity checking support in ABCMeta

Changes by Łukasz Langa : -- keywords: +patch Added file: http://bugs.python.org/file30366/issue16832.diff ___ Python tracker ___ ___

[issue16832] Expose cache validity checking support in ABCMeta

Antoine Pitrou added the comment: > 1. Some of the cached entries may never be accessed again, so > recalculating them will be a waste > 2. The object graph may change again before they're next accessed, so > recalculating any entries at all will be waste Yup, hence the "cost/benefit compromise"

[issue16832] Expose cache validity checking support in ABCMeta

Nick Coghlan added the comment: Ah, but that's the other trick: we *don't know* if we need to recalculate our whole cache when the object graph changes. 1. Some of the cached entries may never be accessed again, so recalculating them will be a waste 2. The object graph may change again before

[issue16832] Expose cache validity checking support in ABCMeta

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 registrat

[issue16832] Expose cache validity checking support in ABCMeta

Nick Coghlan added the comment: And when I say "originally" I mean "after I saw how ABCs already implemented this capability" :) -- ___ Python tracker ___ __

[issue16832] Expose cache validity checking support in ABCMeta

Nick Coghlan 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. (More accurately: it's almost always going to be

[issue16832] Expose cache validity checking support in ABCMeta

Antoine Pitrou added the comment: Rather than exposing the "cache token" (which looks like an implementation detail), you may allow third-party code to register a handler which will be called when an ABC's registrations are modified: def abc_handler(abc): """ Called when the concrete c

[issue16832] Expose cache validity checking support in ABCMeta

Łukasz Langa added the comment: This will be useful for PEP 443. >From Nick's comment on python-dev >(http://mail.python.org/pipermail/python-dev/2013-May/126535.html): "Given the global nature of the cache invalidation, it may be better as a module level abc.get_cache_token() function."

[issue16832] Expose cache validity checking support in ABCMeta

Changes by Daniel Urban : -- nosy: +daniel.urban ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue16832] Expose cache validity checking support in ABCMeta

New submission from Nick Coghlan: ABCMeta uses an internal counter to invalidate the negative caches when a register() call changes the virtual inheritance graph. (A global count of register() calls is stored on ABCMeta, which ABCMeta.__instancecheck__ and ABCMeta.__subclasscheck__ then compar