[Python-ideas] Syntax: 'return: ...' expressions

Andrew Barnert abarnert at yahoo.com
Tue Jan 6 09:25:25 CET 2015


On Jan 6, 2015, at 2:59, Yawar Amin <yawar.amin at gmail.com> wrote:

> On 2015-01-05 04:49, Andrew Barnert wrote:
> 
>> You also seem to have invented a rule that a sequence of statements
>> has the value of the last statement as its value. Which requires first
>> inventing a rule that gives values to statements. I'll assume you
>> wanted to go with the same rule the interactive interpreter uses to
>> display a last value--an expression statement has its expression's
>> value, and any other kind of statement has None?)
> 
> No, I was trying to say that whatever's inside the 'return: ...' block
> is evaluated, and then the last expression inside the block becomes the
> value of the block as a whole. No change would be required to any
> existing expressions or statements, or to the result of a normal
> sequence of statements.

I think you're missing another important point here: statements and expressions are different things. Blocks are made up of statements, not expressions, and statements don't have values. This is different from many other languages like C, Ruby, or JavaScript, where as many things as possible are expressions (and therefore have values), so a block is (oversimplifying a bit) just a sequence of expressions separated by semicolons and stuck inside braces, and therefore it has a last value.

One type of statement, the expression statement, is just an expression on a line by itself (or between semicolons), so you _could_ invent a rule pretty easily that expression statements have the value of their expression, and all other statements have a value of None, and a block has the value of its last statement. This is basically the same rule used by the interactive REPL for displaying the repr of what you've typed and setting the _ variable, so it wouldn't be a huge stretch to add the same rule to the language itself--but it would still be a new rule, and a significant change to the internals of the interpreter, even though it would only be useful in this new context.



More information about the Python-ideas mailing list