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

[Andrew Barnert]

On Feb 16, 2014, at 18:06, "Joao S. O. Bueno" <jsbueno at python.org.br> wrote:

> 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

Clever.

What happens if expensive_computation() raises? Does the push get ignored? Capture the exception, push it, and re-raise, so the next pop will raise the same exception?

Is there any reason this has to be local? If it were, say, a thread-local global, it could be used to wedge additional arguments through functions that weren't expecting them. (Together with a "mark" function of some kind you could even use this to experiment with alternate calling conventions, etc.)

I still don't see how this fills a gap that needs to be filled; how is the first version any more readable, writable, concise, whatever than the second?

    if push(expensive()):
        x = pop()
        dostuff(x)

    x = expensive()
    if x:
        dostuff(x)

But it's a clever idea even if it doesn't help there.

> 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/
> _______________________________________________
> 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/