@shaypal5 I know this is not what you suggested in #46 (comment), but hear me out for a bit:

I realized there was a need to encapsulate the is_from_cache() information, i.e. localized to the decorated function. In the existing code, there are provisions for manipulating the cache specific to the decorated function, such as clear_cache(). My implementation here follows that paradigm.

API-wise, you're right ― there are existing precedents to modifying, and actually enhancing, the decorated function's API with additional attributes, such as clear_cache().

However, the use case here is different. clear_cache() clears an attribute that is unique to the function ― its cache ― and it thus make sense that the function is bound to the decorated function. In your case, the action is bound to a specific call of the function, and thus this is inherently not appropriate to bound it to the function, but rather to the call.

The practical implication is that this API is indeed not thread-safe: You might call is_from_cache() straight after the call to foo(), and still get an irrelevant result if another call to foo() was made in another thread between the two calls. Since at the moment a significant feature of cachier ― and one which some work went into ― is that it is thread-safe, I would prefer not to break it for the current implementation suggestion.

I still think a simple listener object is the way to go, since it is bound to the call rather than the function. This is like future objects in various programming languages, that are implemented as per-call instances you get and query. So yeah, maybe something like this:

call_info = cachier.Info()
foo(cachier_info=call_info)
if call_info.is_from cache:
    # do something

The more general name and structure of a call information object is intentional, since this is an easily expandable API, onto which we can graft additional functionalities for call-specific information (an obvious and useful example: get the time in which the value in the cache was produced).

Let me know what you think!
Shy

Ah, wonderful. And here I thought I was being thread-safe by localizing the query but as you point out, it's exactly the opposite. Let me take another swing at it!

Regarding thread-safety, here is how I imagine a demonstration:

from random import random
from cachier import cachier, Info
from concurrent.futures import ThreadPoolExecutor

@cachier()
def foo(arg):
    return random()

# This is thread-safe
# Info object is unique to every call of caller (and subsequently, foo)

def caller(arg):
    call_info = Info()
    result = foo(arg, cachier_info=call_info)
    return {
        'result': result,
        'arg': arg,
        'is_from_cache': call_info.is_from_cache
    }

with ThreadPoolExecutor(max_workers=2) as pool:
    arglist = [1, 2, 3, 1]
    results = list(pool.map(caller, arglist))


# This is NOT thread-safe
# Info object is shared among all concurrent calls of caller

call_info = Info()

def caller(arg):
    result = foo(arg, cachier_info=call_info)
    return {
        'result': result,
        'arg': arg,
        'is_from_cache': call_info.is_from_cache
    }

with ThreadPoolExecutor(max_workers=2) as pool:
    arglist = [1, 2, 3, 1]
    results = list(pool.map(caller, arglist))

Is that how you envisioned it, @shaypal5?

Just writing to say I didn't forget this. This is on my TO-DO list for very soon. :)

Yes, that looks good!

I'm sorry for the extremely belated response!
You want to change the PR accordingly, so we can iron out the details?

Closed after being stale for a long time.
Please open a new PR if you with to contribute this feature at some point in the future.