Forgetting "()" when calling methods

[Andrew Bennetts]

On Sun, Apr 27, 2003 at 10:48:39AM +0000, Alex Martelli wrote:
> Andrew Bennetts wrote:
> 
> > On Sun, Apr 27, 2003 at 07:38:47AM +0000, Alex Martelli wrote:
>    ...
> >> See?  PyChecker CAN and DOES warn about "this case"!  But OF COURSE
> >> it can't help with the following erro1.py:
> > 
> > Sure, but I said: "removing __nonzero__ from functions still doesn't help
> > this case".  You can catch that today, with PyChecker, as you've
> 
> I.e., it doesn't help with a case that doesn't really need help -- is THAT
> the "point" you thought it was worth a post to make (and DIDN'T mention!)?

It just seemed like you ignored my point, and then proceeded to show that
pychecker is sometimes helpful.  I was trying to say that I was aware of
that, and it didn't affect my opinion.

> There are a zillion cases where no "help" is particularly needed nor
> warranted.  The fact that any proposed change "doesn't help" with any
> subset of the cases that don't particularly need help is so clearly
> irrelevant to any assessment of that proposed change that I _still_
> don't see why ever one would want to start enumerating such cases.

Ok, the meta-arguments are getting so convoluted I propose we just give them
up and stick to the actual underlying argument :)

> > It's still not a justification for breaking __nonzero__ on functions. 
> 
> Would it damage you if that __nonzero__ raised a warning that is
> suppressed by default, but can easily be (selectively) enabled?

Yes -- if it's a PendingDeprecationWarning or similar, that suggests what I
consider a perfectly good idea will at some point be removed from the
language.  If it's a new kind of warning that is merely a "Hey!  If you're a
newbie and want handholding, you might want to double-check this", then
that's ok with me.  If possible, I think that sort of thing belongs in
PyChecker, along with various other warnings with high false positive rate.

> > There are plenty of cases where "if func:" is perfectly valid, and no
> > amount of "SINERGY" is going to convince me that making that fail (either
> > in PyChecker or at runtime) is a good idea :)
> 
> I apologize for the misspelling, but it doesn't affect my argument.

Sorry; that was a low blow on my part.  It was the combination of the
misspelling, the ALL-CAPS, and the word "synergy" (which I have trouble
taking seriously at the best of times ;) that somehow affected my judgement.

> You mentioned that you have no extensive experience teaching newbies,
> particularly ones that come from the many languages where trailing
> empty parentheses are not necessary to call an argument-less function,
> such as Pascal and its descendants, as well as Visual Basic.  Yet it
> is exactly to help such newbies that I'm considering making __nonzero__
> raise an optional warning for function and method objects -- help them,
> together with PyChecker for the diagnosis of other cases, get info
> ASAP about the fact that once again they've forgotten a trailing '()',
> rather than having to deduce it from subtle errors arising later and
> quite possibly in quite separate points of their code.

I do have some relevant experience here, if only a little: I used to do alot
of VB before I started doing alot of Python, and for a fair while in the
middle I did alot of both.  So I *did* occasionally make this very error,
because I was switching between languages -- but never did it cause me more
than a couple of seconds' worth of anguish.  That's the basis upon which I
consider this proposed change to be unjustified, especially given that I 
consider it more useful the way it is.

[Oh -- and I *do* have some experience teaching Python to a class of
newbies, I just remembered, but just one class.]

-Andrew.