Forgetting "()" when calling methods

Alex Martelli aleax at aleax.it
Sat Apr 26 12:42:33 EDT 2003


Klaus Meyer wrote:

>> I don't know what to DO about it, but some minor tweaks might help.
> 
> I also have made this mistake sometimes.
> 
> On reason, i think, is the mix of function-call and values, example:
> 
> import time
> print time.time()
> print time.timezone
> 
> You have to remember the doc of the module carefully to make no mistake.

Well, in this case it's no big deal, actually -- 

>>> print time.time
<built-in function time>

i.e. if you forget parentheses you get an immediate reminder of that.


> In this case time() must be a function, because it has to read the actual
> timer value, but must timezone be a value?

There is NO case in which something "HAS" to be a value -- it's just
handier and faster and neater when it CAN be.

> My question about style:
> Should a Module/Class etc. return values, if possible, or better use
> function to return values?

If arguments are needed, then of course functions / methods.

If arguments *aren't* needed, then a class instance gives you more
freedom of choice, as you can define *properties* -- user code
syntactically accesses a property without any overt function call,
but "under the covers" Python calls a method you have designated
to be the "getter" when buildint the property.  The ability to start
with a simple attribute access -- and turn it into a getter-call at
any time that may be needed, without any need for changes in code
using it, is really crucial, and a good motivation to NEVER design
"argumentless getter methods that just access what's really and
conceptually a simple stored attribute value" into your classes.


> If PyChecker could check such cases this would be very helpful.

When you're actually DOING something with the function or method object,
even if what you're doing is not *calling* them, it's basically out of the
question -- apparently not even testing truth value can be removed, due
to the "x=getattr(someobject, attrname, None)" usage followed by testing
just for truth value ("if x:") rather than for None-hood ("if x is None:").

A checker that gives lots of false positives soon becomes worse than
useless, makes you waste more time than it gains you, and withers.

So, I think your best bet is to apply the metaclass I already posted,
selectively, to modules you're writing, and hopefully quite transiently
as you proceed to learn that "to call callables, you need to CALL them"
and not just MENTION them.


Alex





More information about the Python-list mailing list