[Python-ideas] Re: Generalized deferred computation in Python
On Tue, Jun 21, 2022 at 4:55 PM David Mertz, Ph.D. wrote: > I haven't gotten to writing that into the PEP yet, but I think the rule > has to be to take the scope of evaluation not the scope of definition. I > know it needs to be there, and I'm just thinking about helpful examples. > > Which is to say the semantics are more like `eval()` than like a lambda > closure. > > ... and I know this is going to raise the neck hairs of many folks, > because effectively I'm proposing a kind of dynamic scoping. > I’ll be curious to see the rationale for this in the PEP, because it seems like clearly the wrong choice to me. It turns the feature from “delayed computation” into something much stranger that I doubt I would support. If the motivation is “so it can be used in argument default values and subsume PEP 671,” I think that’s a bad reason. IMO putting complex default values that would require delayed evaluation into the function signature line is net harmful (because of the pass through problem) so I oppose both PEP 671 and the use of deferred evaluation for that purpose. Possibly in my defense, I think Carl's PEP 690 can do the same thing. :-) > I’m not sure what you mean. I don’t think there’s any way PEP 690 can introduce dynamic scoping like this. Can you give an example? 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/VCEYMAAV6YF454UT5MPQJMFDJH2TI6R7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Generalized deferred computation in Python
On Tue, Jun 21, 2022 at 4:28 PM Chris Angelico wrote:
> On Wed, 22 Jun 2022 at 08:21, Carl Meyer via Python-ideas
> wrote:
> >
> >
> >
> > 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
> 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.
> >
>
> It would have to be non-assignable and probably a keyword. Otherwise,
> the exact same issues will keep occurring.
Mmm, you’re right. It would either need to be handled specially in the
compiler, or it would have to use the PEP 690 approach of
`is_lazy_import(globals(), “name”)` where it takes both the namespace
dictionary and the key as string, to avoid triggering reification.
What are the scoping rules for deferred objects? Do they access names
> where they are evaluated, or where they are defined? Consider:
>
> def f(x):
> spam = 1
> print(x)
>
> def g():
> spam = 2
> f(later spam)
>
> g()
>
> Does this print 1 or 2?
>
> This is a fundamental and crucial point, and must be settled early.
> You cannot defer this. :)
Yes, I agree this is a crucial point, and the answer (which is already
somewhat implied by the analogy to lambdas) should be that it closes over
the definition scope (just like defining a lambda or online function would.)
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/X7QB4DCRAB23S4I7PZSUFLTH5LMB35LA/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Generalized deferred computation in Python
On Tue, Jun 21, 2022 at 4:10 PM David Mertz, Ph.D.
wrote:
> On Tue, Jun 21, 2022 at 5:53 PM Brendan Barnwell
> 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/
