On Thu, Jun 23, 2022 at 2:53 AM Chris Angelico <rosuav@gmail.com> wrote:
On Thu, 23 Jun 2022 at 11:35, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
> Martin Di Paola wrote:
> > Three cases: Dask/PySpark, Django's ORM and selectq. All of them
> > implement deferred expressions but all of them "compute" them in very
> > specific ways (aka, they plan and execute the computation differently).
> So - I've been hit with the "transparency execution of deferred code" dilemma
> before.
> What happens is that: Python, at one point will have to "use" an object - and that use
> is through calling one of the dunder methods. Up to that time, like, just writing the object name
> in a no-operation line, does nothing. (unless the line is in a REPL, which will then call the __repr__
> method in the object).

Why are dunder methods special? Does being passed to some other
function also do nothing? What about a non-dunder attribute?

Non-dunder attributes goes through obj.__getattribute__  at which point evaluation
is triggered anyway.

Especially, does being involved in an 'is' check count as using an object?

"is" is not "using', and will be always false or true as for any other object.
Under this approach, the delayed object is a proxy, and remains a proxy,
so this would have side-effects in code consuming the object. 
(extensions expecting strict built-in types might not work with a
proxy for an int or str) - but "is" comparison should bring 0 surprises.

dflt = fetch_cached_object("default")
mine = later fetch_cached_object(user.keyword)
if mine is dflt: ... # "using" mine? Or not?

Does it make a difference whether the object has previously been poked
in some other way?

In this case, "mine" should be a proxy for the evaluation of the call
of "fetch_cached_object" which clearly IS NOT the returned
object stored in "dflt".

This is so little, or so much, surprising as verifying that "bool([])" yields False: 
it just follows the language inner workings, with not special casing.

Of course, this if this proposal goes forward - I am just pointing that the
existing mechanisms in the language can already support it in a way
with no modification. If "is" triggering the resolve is desired, or if
is desired the delayed object should  be replaced "in place", instead
of using a proxy, another approach would be needed - and
I'd favor the "already working" proxy approach I presented here.

(I won't dare touch the bike-shedding about the syntax on this, though) 

Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HUJ36AA34SZU7D5Q4G6N5UFFKYUOGOFT/
Code of Conduct: http://python.org/psf/codeofconduct/