On Feb 16, 2014, at 18:06, "Joao S. O. Bueno" <jsbueno@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@gmail.com> wrote:
On Sat, Feb 15, 2014 at 12:40 PM, Nick Coghlan <ncoghlan@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/