Forgetting "()" when calling methods

[Alex Martelli]

Klaus Meyer wrote:

> On Sat, 26 Apr 2003 16:42:33 GMT, Alex Martelli <aleax at aleax.it> wrote:
> 
>> as you proceed to learn that "to call callables, you need to CALL them"
> 
> You misunderstand me (and the OP, i think). It's not a problem of
> understanding, it's a simple type error or a "false remember" (or a
> "Flüchtigkeitsfehler" in German, i don't know a translation).
> Programmers sometimes make simple mistakes ;-)

I think the misunderstanding is probably the other way around.  I know
perfectly well that we all make simple mistakes: but if the right way
to do something is constantly reinforced, then gradually and eventually
we LEARN, and the mistake becomes extremely rare.

Take addition and multiplication, for example.

How often do you make the mistake of omitting parentheses in THAT case?
I.e. coding "a+b*c" when you actually MEAN "(a+b)*c"?  Pretty rarely, I
suspect -- because the relative priorities of + and * have been drilled
into you for decades, you know DEEPLY that you need parentheses here.

So: the problem is a transient one -- reinforcing the right way to do
it until the neural pathways associated with it dominate the ones that
are associated with the wrong way, giving error messages for the error
as soon as feasible to minimize the cost of the learning.  By LEARNING
here I mean DEEP learning -- the kind that makes errors extremely rare --
not just the superficial kind, limited to the conscious level, where you
have to think and pay deliberate attention to avoid the mistake.


> from the OP:
> 
> if object.isGreen:
>         do something...
> 
> PyChecker could (optional?) warn in such cases if isGreen is a function.

I suspect there may be a very deep misunderstanding here about the
nature of PyChecker -- which works by STATICAL examination of your
module's bytecode -- or else of the degree of difficulty involved in
determining what type "object.isGreen" could possibly BE, in general,
by means of such a statical examination (as opposed to EXECUTING the
code).  To prove that "object.isGreen" is indeed a function, without
actually executing the code but rather by statical examination,
PyChecker would have to prove it can examine ALL pathways the code
could possible have been taken from the execution of the class statement
from which 'object' (what a horrid name choice, duplicating the name
of a built-in type!) is instantiated, or the point of instantiation,
up to this point of execution -- and that in NONE of those paths is it
EVER possible for 'object.isGreen' to have be rebound to any instance
of any different type.  The problem in the general case is obviously
insoluble (it's Turing's so-called "halting problem", or isomorphic to
it).  I very much doubt that the special cases that might perhaps be
resolved with a bounded effort of static examination are worth the
huge amount of development effort.

A vastly more feasible pathway is the one which I proposed, and which
you appear to keep arguing against by stubbornly going back to the
desire of PyChecker (i.e., statical examination) taking care of it --
INSTRUMENT the code, so that when it actually EXECUTES, an exception
is raised at runtime IF the bound-method is evaluated in a boolean
context such as this one.

However, if the very people I'm trying to help here -- those who are
prone to forgetting parentheses when they need to call something
without arguments -- keep stubbornly arguing that the approach I
propose, and which I believe is the only viable one (although very
partial indeed in its support for them), is not what they want -- well,
tough luck... I know when I'm defeated.  If the only (partial) solution
you can possibly HAVE is so irredeemably distant from anything you
would ACCEPT, then there is absolutely nothing either I, or anybody
else, can do for you.  Please accept my apologies for misguidedly
trying to help you guys.


Alex