Useless expressions [was Re: Undefined behaviour in C]

[Steven D'Aprano]

On Mon, 28 Mar 2016 01:43 am, BartC wrote:

[... talk about function and procedures ...]
> 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.)


I think that the only suggestion that might, *just barely*, work in Python
is forbidding the evaluation of a single name as a syntax error. Any other
expression would have to still be allowed.

Advantage:

- catches various errors, such as forgetting to call 
  procedure-like functions:

    main  # oops, meant main()


  or mistyping a keyword:

    for x in sequence:
        if condition: next  # oops, meant continue



Disadvantages:

- makes it less convenient to use the `try: name except NameError` idiom.

- won't do anything about errors like this:

   x = y  # oops, meant to call y()
   a = b  # this one is okay though

- it treats a single name as a special case of arbitrary 
  expressions. What's so special about the single name case
  that we should guard against this:

    name

  but not this?

    name.validate


The Zen of Python has something to say about special cases.

import this



Now, I happen to think that using "name.validate" for the side-effects of
the attribute look-up is a terrible idea. But it's legal code, and the
compiler shouldn't make value judgements about good or bad code. You want
value judgements, use a linter.



-- 
Steven