Undefined behaviour in C [was Re: The Cost of Dynamism]

BartC bc at freeuk.com
Sun Mar 27 12:58:06 EDT 2016


On 27/03/2016 16:48, Ned Batchelder wrote:
> On Sunday, March 27, 2016 at 10:43:49 AM UTC-4, BartC wrote:
>> On 27/03/2016 14:47, Dennis Lee Bieber wrote:

>> Well, that could be done in Python (not so usefully because you can't
>> take account of such info until a call is attempted), but that's not
>> what I'm talking about, which is simply allowing:
>>
>>     fn(...)
>>
>> whether fn has an explicit return or not, and not allowing:
>>
>>     fn         # and other kinds of expression
>>
>> unless some keyword is used. (I've no idea what that might be; all the
>> best ones are taken. But I've already said a keyword can be emulated via
>> a dummy function call.)
>
> Python *could* have made it an error to have a useless expression as a
> statement.  It would prevent certain kinds of errors.  But it would also
> complicate the language.  How do we decide what is a "useless expression"?

Probably one that would raise eyebrows when used as an expression. Such 
as 'f()+1', even though f() might have useful side-effects.

> As we've seen this might be an expression with a side-effect:
>
>      foo.bar
>
> though it would be unusual.  Should it be forbidden?

No. The language can require a prefix, or the coder can put it into a 
legal form (pass it to a dummy function for example).

> And how do we make docstrings, which are simply string literals as
> statements?  Or do we allow those?  Perhaps we only allow those if they
> are the first statement in a module, class, or function?  How complicated
> do we want these criteria to become?

There would be a list of expression terms that can also form independent 
statements. Not knowing Python, the list would comprise function calls 
(ie. the function call is top node in the AST of the expression), and 
docstrings.

(In other languages it might also include assignments and increments.)

The suggestion has also been made only bare names should be disallowed, 
which would probably trap most of the errors it causes, early on.

> One of Guido's principles in designing Python was to keep it simple,
> even where that might mean people could make errors with it.  This part
> of the language is no different: any expression can be a statement.

Yeah, but even simpler would be that any statement can also be an 
expression! He didn't go that far though.

-- 
Bartc



More information about the Python-list mailing list