[Python-ideas] if expensive_computation() as x:

[Joao S. O. Bueno]

I am stepping late on the thread -
but the wish for having a short cut for:

if expensive_computation_0():
        x = expensive_computation_0()
        # Do something with x...

And havign dealt before with languages where one explicitly deal with
the operanbd stack (like postscript), lead me to deploy this very simple
module I called "stackfull" (in a wordplay with "stackless") -

The functions in there simply annotate a list in the locals() dict of
the current
running frame (which cannot be accessed as a variable), and work as
stack operators
on that list -
so the situation above become:

if push(expensive_computation_0()):
        x = pop()
        # Do something with x...

(all functions return the original operand, besides side effects on the "stack")
It was devised most as a toy, but my wish was to fill the gap Python
has for this pattern -
so, if anyone is interested in invest in this idea so that we could
have a nice, real useful thing
to be used in the near future, be my guest.

https://pypi.python.org/pypi/stackfull
https://github.com/jsbueno/stackfull

On 14 February 2014 23:43, Chris Angelico <rosuav at gmail.com> wrote:
> On Sat, Feb 15, 2014 at 12:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> If the handling is identical, there's no need for an if/elif chain at
>> all, otherwise the revised if/elif chain is based on the attributes of
>> the match object.
>
> If the handling's identical, short-circuiting 'or' will do the job.
> Assume it's not.
>
>>> Removing one is just deleting its elif and corresponding block of
>>> code. They are peers. The fact that Python doesn't currently have
>>> syntax that allows this *in an elif chain* doesn't change this; if you
>>> were to write it as pseudo-code, you would write them as peers. That's
>>> why the function-with-return or loop-with-break still looks better,
>>> because it structures the code the way that logically makes sense -
>>> flat, not nested.
>>
>> That doesn't mean embedded assignments are the answer though - they're
>> a sledgehammer solution that is tempting as a workaround for larger
>> structural issues.
>
> I agree that embedded assignment isn't necessarily the answer. I just
> think that a solution that has them all at the same indentation level
> makes more sense than one that nests them inside each other, for
> exactly the same reason that we have 'elif' in the first place.
>
> ChrisA
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/