On Tue, Jun 21, 2022 at 4:10 PM David Mertz, Ph.D. <david.mertz@gmail.com> wrote:
On Tue, Jun 21, 2022 at 5:53 PM Brendan Barnwell <brenbarn@brenbarn.net> wrote:
> In the example, we assume that the built-in function `type()` is special
> in not counting as a reference to the binding for purpose of realizing a
> computation. Alternately, some new special function like `isdeferred()` might be used to
> check for ``Deferred`` objects.

I'll have to ponder my thoughts about the proposal as a whole, but this
particular aspect seems dubious to me.  As I understand it this would
require some fairly deep changes to how evaluation works in Python.
Right now in an expression like `type(blah)`, there isn't any way for
the evaluation of `blah` to depend on the fact that it happens to occur
as an argument to `type`. 

I absolutely agree that this is a sore point in my first draft.  I could shift the magic from `type()` to `isdeferred()`, but that doesn't really change anything for your examples.  I suppose, that is, unless `isdeferred()` becomes something other than a real function, but more like some sort of macro.  That doesn't make me happy either.

However, I *would* like to be able to answer the question "Is this object a DeferredObject?" somehow.  For example, I'd like some way to write code similar to:

if isdeferred(expensive_result):
    log.debug("The computationally expensive result is not worth calculating here")
    log.debug(f"We already hit a path that needed the result, and it is {expensive_result}")

Any thoughts on what might be the least ugly way to get that?

I think all it really requires is for isdeferred() to be a builtin implemented in C rather than Python. It will be much better IMO to have isdeferred() returning a bool and not have any deferred object/type visible to Python. 

I think this PEP, although perhaps motivated by PEP 671 discussion, is really a generalization of PEP 690 (the lazy imports PEP.) The best implementation would be almost identical (relying on the dictionary implementation to reify lazy values on access), it’s just that lazy objects would have to be generalized to hold any expression, not only an import.

The updated and more detailed draft of PEP 690 might be interesting reading here: