How to make Python interpreter a little more strict?

[BartC]

On 26/03/2016 23:30, John Pote wrote:

> So intrigued by this question I tried the following
> def fnc( n ):
>      print "fnc called with parameter '%d'" % n
>      return n
>
> for i in range(0,5):
>      if i%2 == 0:
>          fnc
>          next
>      print i
>
> and got the same result as the OP

> A couple of tests showed that the only important thing about the name in
> the if clause is that it is known at runtime and then it is silently
> ignored.
> However, if the name is not known/accessible at run time a 'NameError'
> is raised,
> NameError: name 'mynewfn123' is not defined
>
> On the other hand the following if clause
>      if i%2 == 0:
>          fnc    next

The results aren't surprising once you know what's going on.

If you have:

    fnc

then this name is evaluated (it refers to a function object given your 
definition. Then that value is discarded. But this:

    kljgkjhgjk

is not defined anywhere, and it can't evaluate it, raising the name 
error. While in:

    fnc()

the 'fnc' is evaluated, and then it's called (when it should give a 
parameter error as your def expects one). But

    abc def

is just a syntax error as usually two identifiers can't be adjacent 
(AFAIK) except where the first is a reserved word.

> So I have sympathy with the OP, I would expect the compiler to pick this
> up - indeed it does so for two (or more ?) unused names on a single
> line. That is unless someone can give a useful use of this behaviour or
> is there something going on under the Python hood I'm not aware of?

This one of those features I think that do have the odd use but most of 
the time just result in perplexing results or hard-to-find bugs. It 
could have been eliminated from the language (especially as many people 
aren't even aware of the possibilities) with little loss.

Someone who desperately wants to evaluate a name or expression can 
always use something like:

  def test(x):pass

  test(fnc)

for the same purpose. But this time it's obvious. (Ideally it would be a 
built-in construct to avoid the call overhead.)


-- 
Bartc