How to check whether the proxy is resolved or not

ionelmc / python-lazy-object-proxy

A fast and thorough lazy object proxy.

BSD 2-Clause "Simplified" License

247 stars 36 forks source link

How to check whether the proxy is resolved or not #41

Closed hhsecond closed 3 years ago

hhsecond commented 4 years ago

Thanks a lot for the wonderful package I was wondering if there is a mechanism to check whether the factory function is being called or not, may be allowing to check?

if obj.__target__ is None

ionelmc commented 4 years ago

It would depend on the implementation. I guess I could add a standard way of telling if it holds the instance or not (like obj.__instance__ or similar) but why do you need this anyway?

ionelmc commented 4 years ago

Thinking more about this, a __isresolved__ bool would be better.

hhsecond commented 4 years ago

Hi @ionelmc, First of all, thanks a lot for taking your time here. I can't express how grateful I am (and so is the folks using your project)

About your suggestion, __isresolved__ sounds better to me too. So my need is a bit involved in the architecture level but the gist is here I have python processes (nodes) composed as DAGs. I prefetch the datapoints from database and provide them as lazy proxies to these nodes. These nodes can use these data points to do different operations but a writer process kept on checking the data changes and write it back to the database. Currently, the assumption I have taken is that, if the data is not resolved then the data is not changed. So I can avoid expensive writes.

While my requirement is quite peculiar, I thought the functionality to check proxy-resolution is quite useful and widely being used already. Currently what I do is to use simple.Proxy and check

"__wrapper__" in proxyobj.__dict__

ionelmc commented 3 years ago

So I would like to add this property in the next release but I'm not sure about the name. It has to be something unique enough and double underscored (to increase uniqueness). It has to avoid british/american spelling differences, and be pretty obvious.

My candidates:

__isresolved__ - bad because of ambiguous spelling - is it resolved or rezolved? who knows
__resolved__ - same problem, and also, I wonder if it's worth having the "is" prefix at all
__materialized__ - same problem (materialised), also kinda long
__completed__
__instantiated__ - kinda long, but very good otherwise
__has_instance__ - still long
__reified__ - short, unique but kinda obscure?
__formed__ - maybe not very obvious of what it'd represent?

Hmmm... perhaps there's some terminology already established in the stdlib?

ionelmc commented 3 years ago

On second thought perhaps reusing terms from stdlib would be a bad idea. So I've found __cached__ which would seem suitable but would conflict with the interface here https://docs.python.org/3/library/importlib.html#importlib.abc.Loader.load_module

ionelmc commented 3 years ago

How about __called__ or even __factory_called__ (no confusion about if it means that __call__ was used)?

ionelmc commented 3 years ago

So turns out no one spells "rezolved". Anyway, not using the "is" prefix as it seems to have a "call interface" in the stdlib (eg: somestr.isdigit()).