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
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 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,
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 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
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
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
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
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 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
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
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
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 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
> result = bar or default
I used to do this, but dropped this habit. Just to be on the safe side if in
the future I extend bar to take value for which truth test evaluates to False.
And for consistency across the codebase.
___
Python-ideas mailing
> I think that's reasonable. But I don't think Python is the language
> for that. There are too much existing contrasts, such as loop vs.
> comprehension and conditional statement vs. ternary expression. Guido
> deliberately chose to vary those expression syntaxes from their
> statement
On Thu, Jul 20, 2023, 01:19 Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
>
>
> On 15/07/2023 21:08, Dom Grigonis wrote:
>
> Just to add. I haven’t thought about evaluation. Thus, to prevent
> evaluation of unnecessary code, introduction of C-style expression is
> needed anyways:
17 matches
Mail list logo
