On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
wrote:
> I didn't like that PEP then; I was in the camp of "let's get genuine
> Deferreds, and use them to cover some of the use cases for PEP 671."
You're almost certainly never going to get that, because "genuine
Deferreds", as well as being nea
Thanks, thats truly useful to keep in mind.
> On 20 Jul 2023, at 09:48, anthony.flury wrote:
>
>
> The challenge with anything like
>
> result = default if bar is None else bar
>
> or
> result = bar if bar else default
>
> or even
>
> result = bar is None ? default : bar
>
>
> is that
On Thu, 20 Jul 2023 at 17:09, Dom Grigonis wrote:
>
> On 20 Jul 2023, at 09:48, anthony.flury wrote:
> In Python then a better way might be
>
> result = temp := bar() if temp else default
>
> This way only bar() and default are evaluated and invoked once.
>
I presume you want a more complicated
On 20/07/23 6:30 pm, James Addison via Python-ideas wrote:
result = default if bar is None else bar
or if you prefer
result = bar if bar is not None else default
Would it shut anyone up if we had another logical operator:
x otherwise y
equivalent to
x if x is not None els
On Thu, 20 Jul 2023 at 18:16, Greg Ewing wrote:
>
> On 20/07/23 6:30 pm, James Addison via Python-ideas wrote:
> > result = default if bar is None else bar
> > or if you prefer
> > result = bar if bar is not None else default
>
> Would it shut anyone up if we had another logical operat
I have looked more properly at deferred evaluation and late-bound defaults.
Deferred-eval is overkill for what I need and isn’t likely to come about soon,
while deferred only solves a very small part of what I am looking at. Also, it
lacks ability to enforce default from outside, which is a bit
On Thu, 20 Jul 2023 at 19:34, Dom Grigonis wrote:
> And ideally, adding 2 builtin(or imported from stdlib) functions: `Break` and
> `Continue`, which if called act as `break` and `continue` statements.
>
How would they work? Would every function call have to provide the
possibility to return to
Ok, this is tricky.
So pretty much impossible, given that `Break`, if it was to work has to be
evaluated in reference scope, while other delayed objects in their definition
scope.
--
Back to deferred evaluation.
--
Giving it a rest for a while. Thank you
Chris Angelico writes:
> On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
> wrote:
C'mon Chris, "that was then, this is now". Catch up, I've changed my
position. ;-)
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an em
On Thu, 20 Jul 2023 at 22:27, Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
> > On Thu, 20 Jul 2023 at 15:33, Stephen J. Turnbull
> > wrote:
>
> C'mon Chris, "that was then, this is now". Catch up, I've changed my
> position. ;-)
>
That's fair :) Maybe I'll dust off that proposal agai
On Mon, Jul 17, 2023, at 16:41, Dom Grigonis wrote:
> Would be interesting to see if my preference is an outlier or not really.
I think this is a false dichotomy. We should consider VB-like conditional
expressions if(condition, when_true, when_false) as well.
_
On Fri, 21 Jul 2023 at 05:53, Random832 wrote:
>
> On Mon, Jul 17, 2023, at 16:41, Dom Grigonis wrote:
> > Would be interesting to see if my preference is an outlier or not really.
>
> I think this is a false dichotomy. We should consider VB-like conditional
> expressions if(condition, when_true,
That is where I got to really. Ability to construct one’s own expressions,
where evaluation can be controlled. And found out that deferred evaluation is
what would potentially provide exactly what is needed for this.
Making use of ‘function’ protocol seems appropriate as I don’t think inventing
On Fri, 21 Jul 2023 at 11:08, Dom Grigonis wrote:
> Also, can't find a way to ONLY force evaluation without any additional
> operations in this specific library. A simple callable which evaluates if
> unevaluated & returns would do. Then:
>
> def IF(condition, when_true, when_false):
> if co
14 matches
Mail list logo
