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