Proposal: inheritance structure and annotate/validate behaviour

[RonnyPfannschmidt]

while trying to implement a cached property variant that implements a annotate/validate behavior

i noticed that 2 implementation details could be shared in mixins

• all thread support is implemented via adding a lock property and using it in __set__
• ttl is using the current time as "annotation" and uses timedelta > ttl as validation

this would allow for a interesting hierarchy ill propose at the end

the annotate/validate behavior can be considered as a generalization of the ttl model
where ttl is just the annotation/validation based on time/ttl,
while annotate/validate could also do more extended checks like validating database connections
or doing inexpensive cache/db queries for values that where very expensive to query for

Hierachy

• CachedProperty implementing the base behaviour
• _ThreadSafeMixin implementign only the thread lock
• ThreadSafeCachedPropery inheriting fromCachedProperty,_ThreadSafeMixin`
• _AnnotatedCachedproperty implementing annotation/validation behaviour
  • annotation must result in a single object which is stored alongside the actual object
  • validation will receive only the annotation object, and must return a truth value
  • annotation may return the actual object in order to allow validation to use it
• CachedPropertyWithTTL inheriting from _AnnotatedCachedproperty implementing ttl annotation/validation
• AnnotatedCachedProperty. inheriting from _AnnotatedCachedproperty implementing exposure of the annotate/validate api
• the thread-safe variants would just mix in the _ThreadSafeMixin again

since this is a larger structural change, i wanted to discuss before taking a stake at completely implementing it

on a sidenote - i already tried the thread safety unification,
but sharing the code for pessimistic retrieval from __dict__ caused the threading test for the normal cached property to fail

i suspect the gil is involved and i stepped back to discuss the idea at that point since debugging/verifying the gil involvement would eat way too much time right now

[pydanny]

Simply reviewing pull requests for this kind of 2.0 effort is going to be a major effort, comprising more free time than I have to spare. So as much as I think this is an interesting idea, we're going to have to defer it for the time being. 😞

[RonnyPfannschmidt]

so far it hasnt come up in my work anymore as well