On Tue, Jun 21, 2022 at 4:10 PM David Mertz, Ph.D. <david.me...@gmail.com>
wrote:
> On Tue, Jun 21, 2022 at 5:53 PM Brendan Barnwell <brenb...@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")
> else:
> 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:
https://github.com/python/peps/pull/2613
Carl
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/VATY2NIKNDSBE5B5CL3D77ZVYGASFY7G/
Code of Conduct: http://python.org/psf/codeofconduct/
