Coming back to deferred evaluation,
https://peps.python.org/pep-0671/ <https://peps.python.org/pep-0671/>
These 2 aren’t really orthogonal in functionality. Maybe in implementation.
But PEP671 is a certain subset of deferred evaluation as it can achieve the
same with 1 extra line at the start of the function’s body.
------------------------------
Most importantly:
If deferred evaluation had a CONCISE keyword/operator, it would actually solve
my (and several other) requests/proposals.
def ifelse(cond, if_true, if_false):
return if_true if cond else if_false
IF = ifelse
def __init__(self, a=None, b=None):
self.a = ifelse(a is not None, a, ?Foo())
self.b = IF(b is not None, b, `Bar()`)
hopefully it would not be `later`...
This way users could define their own constructs via callables & control order,
evaluation and brevity to their liking.
------------------------------
https://peps.python.org/pep-0463/ <https://peps.python.org/pep-0463/> could
also be achieved with a function.
def trye(expr, err, default):
try:
return expr
except err:
return default
value = trye(`dct[key]`, KeyError, 'No Value')
------------------------------
https://peps.python.org/pep-0505/ <https://peps.python.org/pep-0505/>
def naw(a, b):
if a is not None:
return a
else:
return b
a = None
naw(a, `expr()`)
# OR Infix operator:
a |naw| `expr()`
It starts to seem that it would solve all of the things I was looking at to a
satisfactory degree (given a concise keyword obviously...).
------------------------------
With certain additions, could even break & continue...
from statements import Break, Continue
def ifelsebc(cond, val, else_break=True):
if cond:
return val
elif else_break:
return `Break(0)`
else:
return `Continue(0)`
a = 0
while True:
a += ifelsebc(a < 5, 1, else_break=True)
print(a) # 5
The issue with lambda is that it has to be handled differently, or code has to
check for its possibility, while deferred evaluation integrates seamlessly into
already existing code.
IMO, it would be an excellent addition. And all this would come as a side
effect, rather than main intent (which is dask.delay functionality if I
understood correctly).
How likely you think is it going to happen? Given PEP number it doesn’t sound
very promising...
> On 18 Jul 2023, at 09:45, Chris Angelico <[email protected]> wrote:
>
> On Tue, 18 Jul 2023 at 16:25, Dom Grigonis <[email protected]> wrote:
>>
>> Yes, thank you, this would definitely be nice to have.
>>
>> Although, "A generic system for deferred evaluation has been proposed at
>> times“ sound better if it was a superset of PEP505. Could you refer me to
>> any resources about such considered system?
>>
>
> Hrm, you'd probably have to scour the archives. It's one of those
> things that comes up periodically and spawns a discussion thread, but
> never really gets to a concrete proposal. The best I can find is this,
> which never even got submitted to the official PEP repository, but
> it's someone's attempt to make something that could potentially become
> one, so it's a start.
>
> https://github.com/DavidMertz/peps/blob/master/pep-9999.rst
>
> The trouble is, it's really REALLY hard to pin down useful semantics
> for deferred evaluation. We already have lambda functions, which cover
> a lot of situations, leaving a lot of uncertainty as to what's being
> handled by this new proposal - and since no proposal ever truly comes
> from a single person, that results in a certain amount of chaos.
>
> ChrisA
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/YRGQV3U2GJFHYN2LXLW7PCP7MH22LFWI/
Code of Conduct: http://python.org/psf/codeofconduct/
