Statements as expressions [was Re: Undefined behaviour in C]
BartC
bc at freeuk.com
Tue Mar 29 07:31:51 EDT 2016
On 29/03/2016 09:26, Steven D'Aprano wrote:
> On Monday 28 March 2016 12:40, Paul Rubin wrote:
> The point is that there's nothing intrinsically obvious or right about
> "return the value of the last statement in the block".
But that's exactly what happens inside a typical function: you have
linear sequence of statements, then you a have return statement: at the
end. It's a common pattern.
>>> while True:
>>> x += 1
>>> if condition: break
>>
>> It could return None, or break(val) could return val.
>
> Another arbitrary choice. It *could* return anything. But what *should* it
> return?
It's up to you. Write it like this (not valid Python):
while True: x+=1; if c: break; y
Now this is two statement, the loop, and 'y'. We now have a block, and
because of the block rule, the value is y.
> An expression naturally and intrinsically should return the value the
> expression calculates. This is such a no-brainer that I feel stupid even
> writing it: "x+1" should return "x+1". It would be crazy to pick something
> else.
(This is in contradiction to what you say elsewhere, where:
graph + node
may be procedural.)
> But a statement is a statement because it doesn't have a return value.
Isn't an expression technically a statement in Python? Therefore a
statement could have a value. But take this example:
if cond1: x=a1
elif cond2: x=a2
elif cond3: x=a3
else: x=a4
Clearly this would be better expressed as (not valid Python):
x = if cond1: a1
elif cond2: a2
elif cond3: a3
else: a4
So some kinds of statements could conceivably yield a useful value. (And
each a1, a2 here could be a block or other statement yielding a value.)
> To
> give it one, we have to more-or-less arbitrarily force it to have one, but
> that doesn't make it terribly natural.
>
> del x
>
> Should it return None? The string 'x'? How about the value that x had just
> before it was deleted?
(Actually 'del is a rather odd language feature. And I can't figure out
how it's implemented; how does it manage 'del x[i]'? Anyway that's
another matter.)
> True if that allowed the value to be garbage
> collected, False if it wasn't? Or the other way around? None of these
> suggests feel either useful or obviously right.
It doesn't need to give a useful value. Its 'value' lies in being able
to have it in a sequence or block:
z = del x; y
> The way I see it, all expressions are meaningful as statements (although
> possibly not terribly useful if they don't have side-effects) but not all
> statements are meaningful as expressions.
Yes. But some are. To list a few statements that could return values
(some are not part of Python):
- If-elif-else
- Switch and case select statements
- Block
- Increment
- Subroutine call
- Assignment
The rest can still usefully appear in a block. Python has a version of
if-else that appears in an expression, but it has function-call. But why
stop there?
Anyway this is all hypothetical, in case anyone thinks I'm pushing for a
change in the language. I thought such a language was cool in the 1980s,
but now will settle for a more conservative one even if it's not so elegant.
--
bartc
More information about the Python-list
mailing list