On Wed, 22 Jun 2022 at 11:59, David Mertz, Ph.D. wrote:
>
> Thanks Carl and Chris. After reading your comments, and thinking some more
> about it, I agree you are both correct that it only makes sense to have a
> DeferredObject act like a closure in the scope of its creation. That really
> sh
Thanks Carl and Chris. After reading your comments, and thinking some more
about it, I agree you are both correct that it only makes sense to have a
DeferredObject act like a closure in the scope of its creation. That
really should suffice for anything I could sensibly want; it's enough for
Dask,
On Tue, Jun 21, 2022 at 3:49 AM Marco Sulla
wrote:
>
> On Sun, 19 Jun 2022 at 03:06, Inada Naoki wrote:
> > FWIW, I had proposed str.iterlines() to fix incompatibility between
> > IO.readlines() and str.splitlines().
>
> It's a good idea IMHO. In your mind, str.iterlines() will find only
> \n, \r
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 t
On Wed, 22 Jun 2022 at 08:54, 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
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
On Wed, 22 Jun 2022 at 08:36, Carl Meyer wrote:
>
>
>
> 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.
>> > wrote:
>> >>
>> >> On Tue, Jun 21,
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:
> >
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.
> 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
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. Al
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
On 2022-06-20 22:54, Chris Angelico wrote:
You are welcome to dislike the PEP on the basis that the existing
language is better than it would be with this feature. I personally
disagree, but that's what opinions are. But to object on the mere
basis that something MIGHT, despite demonstrated evide
On 2022-06-21 13:53, David Mertz, Ph.D. 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 ``Def
Here is a very rough draft of an idea I've floated often, but not with much
specification. Take this as "ideas" with little firm commitment to details
from me. PRs, or issues, or whatever, can go to
https://github.com/DavidMertz/peps/blob/master/pep-.rst as well as
mentioning them in this thre
I will post to a different thread for my actual semi-proposal. But to
answer the claim that late-bound arg defaults and late-bound
everything-else are unrelated, and to start with an early version of what
I'd actually want, I wrote this:
https://github.com/DavidMertz/peps/blob/master/pep-.rst
On Tue, 21 Jun 2022 at 10:01, Paul Moore wrote:
> PS To be clear, my objections to the PEP aren't based on deferred
> evaluation. So I'm an impartial 3rd party on this matter. I *do* have
> problems with the PEP, so I have an interest in seeing the PEP fairly
> reflect the lack of consensus, and
On Tue, 21 Jun 2022 at 09:20, Chris Angelico wrote:
>
> On Tue, 21 Jun 2022 at 18:15, Paul Moore wrote:
> > I'm not talking about a "full and detailed specification". That's
> > *still* more than is needed for a valid debate (at this point). But
> > what *is* needed is a more complete explanation
On Tue, 21 Jun 2022 at 18:15, Paul Moore wrote:
> I'm not talking about a "full and detailed specification". That's
> *still* more than is needed for a valid debate (at this point). But
> what *is* needed is a more complete explanation of how deferred
> evaluation would work, and some plausible (n
On Tue, 21 Jun 2022 at 06:27, Chris Angelico wrote:
>
> Okay, here's a compromise.
>
> Go and write a full and detailed specification of the Python-visible
> semantics of deferred evaluation objects, including how they would be
> used to implement late-bound argument defaults.
I'm going to ignore
19 matches
Mail list logo
