On Thu, 23 Jun 2022 at 11:35, Joao S. O. Bueno 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)
On Wed, Jun 22, 2022 at 6:36 PM Joao S. O. Bueno
wrote:
> implement "all possible"
> dunder methods, and proxy those to the underlying object, for a "future
> type" that was
> calculated off-process, and did not need any ".value()" or ".result()"
> methods to be called.
>
Here's a package on PyP
>
> On Wed, Jun 22, 2022 at 02:30:14PM -0400, David Mertz, Ph.D. wrote:
> >But basically, think about `x = (later expensive1() + later expensive2())
> /
> >later expensive3()`. How can we make `x` itself be a zero argument
> >lambda? [... see below ...]
>
x = lambda: (expensive1() + expensive2
The idea is to have a `default_factory` like argument (either in the `field`
function, or a new function entirely) that takes a function as an argument, and
that function, with the value provided by `__init__`, is called and the return
value is used as the value for the respective field. For exa
> No need to have an object there - you could just define it as a syntactic
> construct instead. Assignment targets aren't themselves objects (although the
> same syntax can often be used on the RHS, when it would resolve to one).
Right. Thanks. That _should_ have been obvious. :)
> Having a wa
Thanks Rob,
I recognize that I have so-far skirted the order-of-precedence concern. I
believe I have used parens in my example everywhere there might be a
question... But that's not a general description or rule.
I have a bunch of issues that I know I need to flesh out, many coming as
suggestions
On Wed, Jun 22, 2022 at 11:22:05PM +0100, Paul Moore wrote:
Hang on, did the PEP change? The version I saw didn't have a compute()
method, deferred objects were just evaluated when they were
referenced.
You are right, the PEP does not mention a compute() method but uses the
that term. I just
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 deferr
On Thu, 23 Jun 2022 at 10:44, Rob Cliffe via Python-ideas
wrote:
>
> Thank you for your proposal David. At last we have a counter-proposal to
> talk about. A few points:
>
> (1) (As I pointed out in an earlier post) There is a flaw in using the syntax
> of an expression PRECEDED by a SOFT keyw
Thank you for your proposal David. At last we have a counter-proposal
to talk about. A few points:
(1) (As I pointed out in an earlier post) There is a flaw in using the
syntax of an expression PRECEDED by a SOFT keyword:
x = later -y
With your proposal, x is assigned a deferre
On Thu, 23 Jun 2022 at 08:56, Steve Jorgensen wrote:
>
> This is based on previous discussions of possible ways of matching all
> remaining items during destructuring but without iterating of remaining final
> items. This is not exactly a direct replacement for that idea though, and
> skipping
Steve Jorgensen wrote:
> This is based on previous discussions of possible ways of matching all
> remaining items during destructuring but without iterating of remaining final
> items. This is not exactly a direct replacement for that idea though, and
> skipping iteration of final items might or
This is based on previous discussions of possible ways of matching all
remaining items during destructuring but without iterating of remaining final
items. This is not exactly a direct replacement for that idea though, and
skipping iteration of final items might or might not be part of the goal.
On Wed, 22 Jun 2022 at 22:52, Martin Di Paola wrote:
> Perhaps this is the real focus to analyze. The PEP suggests that
> x.compute() does something *fundamentally* different from just executing
> the intermediate expressions.
Hang on, did the PEP change? The version I saw didn't have a compute()
On Wed, Jun 22, 2022 at 02:30:14PM -0400, David Mertz, Ph.D. wrote:
The difference is in composition of operations. I can write a dozen
zero-argument lambdas easily enough. But those are all isolated.
But basically, think about `x = (later expensive1() + later expensive2()) /
later expensive3(
> On 22 Jun 2022, at 19:09, Paul Moore wrote:
>
> I suspect that you consider evaluation-on-reference as an important
> feature of your proposal, but could you consider explicit evaluation
> as an alternative? Or at the very least address in the PEP the fact
> that this would close the door on
Could this idea be used to specify the default factory of a dataclass
field? For example,
@dataclass
class X:
x: list[int] = deferred []
instead of
@dataclass
class X:
x: list[int] = field(default_factory=list)
If so, it might be worth adding to your proposal as another common
motivating
On Wed, Jun 22, 2022 at 2:17 PM Eric V. Smith wrote:
> Every time I’ve looked at this, I come back to: other than the clunky
> syntax, how is explicit evaluation different from a zero-argument lambda?
The difference is in composition of operations. I can write a dozen
zero-argument lambdas eas
On Wed, Jun 22, 2022 at 10:47 AM Martin Di Paola
wrote:
> Hi David, I read the PEP and I think it would be useful to expand the
> Motivation and Examples sections.
> While indeed Dask uses lazy evaluation to build a complex computation
> without executing it, I don't think that it is the whole st
> On Jun 22, 2022, at 2:12 PM, Paul Moore wrote:
>
> On Wed, 22 Jun 2022 at 18:35, David Mertz, Ph.D.
> wrote:
>>
>> Hi Martin,
>>
>> Short answer: yes, I agree.
>> Slightly longer: I would be eternally grateful if you wish to contribute to
>> the PEP with any such expansion of the Motivat
On Wed, 22 Jun 2022 at 18:35, David Mertz, Ph.D. wrote:
>
> Hi Martin,
>
> Short answer: yes, I agree.
> Slightly longer: I would be eternally grateful if you wish to contribute to
> the PEP with any such expansion of the Motivation and Expansion.
One concern I have, triggered by Martin's Dask,
Hi Martin,
Short answer: yes, I agree.
Slightly longer: I would be eternally grateful if you wish to contribute to
the PEP with any such expansion of the Motivation and Expansion.
On Wed, Jun 22, 2022 at 10:47 AM Martin Di Paola
wrote:
> Hi David, I read the PEP and I think it would be useful t
I think I have an idea how to do something like what you're asking with less
magic, and I think an example implementation of this could actually be done in
pure Python code (though a more performant implementation would need support at
the C level).
What if a deferred object has 1 magic method
Hi David, I read the PEP and I think it would be useful to expand the
Motivation and Examples sections.
While indeed Dask uses lazy evaluation to build a complex computation
without executing it, I don't think that it is the whole story.
Dask takes this deferred complex computation and *plans* h
24 matches
Mail list logo
