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

Joao S. O. Bueno jsbueno at python.org.br
Mon Feb 17 23:59:22 CET 2014


On 17 February 2014 15:46, Andrew Barnert <abarnert at yahoo.com> wrote:
> 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?

As it is today, the operators there are just normal functions (I had
some distant plans of fiddling with Pymacro one of these days to see
if they could be something  different).
So, if "expensive_computation" raises, push will never be called.

>
> 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.)

There is no special reason for it to be local, other than 'a simple
implementation' that would
allow me to have the a value of "expensive_computation()" I could
re-use in the same expression.

>
> 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)

When I wrote it, my need was actually for a pattern in the inline "if"
operation:

x =  pop() if complex_comparison(push(expensive_operation()))  else None
clear()

(again, "complex_comparison" need just not to be that comples, just something
that has to check the value of "expensive()" for anything other than
boolean true/falsiness)

Though I recognize the pattern gets in the way of readability, since
in this case
the pop is placed before the "push" . But if this gets any traction
(even in my personal projects),
maybe writing:

x =  None if not complex_comparison(push(expensive_operation()))  else pop()

might be more recommended.


As I said, it is more or less a toy project, although I had used it
"for real" in some places -
but it does fill a gap I perceive in Python syntax, which is the one
discussed in this thread.

And I am all open to expand "stackfull" into something else, like, for
example, "even use this to experiment with alternate calling
conventions, etc" :-)

  js
 -><-


More information about the Python-ideas mailing list