[Tutor] Philosphy on method naming in modules?

Alan Gauld alan.gauld at blueyonder.co.uk
Fri Sep 5 08:58:07 EDT 2003


> I suppose part of the problem is my approach to using modules.  I
almost
> always used "import foo" rather than "from foo import bar, baz"

That's not a problem, its what you should do.

> ...so I usually end up fully-qualifying the method

Which is absolutely correct and how to avoid name collisions
- thats what modules and import are all about

> the name to something a little less mnemonic, but less likely to
collide
> (say, "UnihanDisplay", "UHDisplay" or some such)?

No that's pointless. Imagine:

import unihan
unihan.unihanDisplay()   urgh, horrible.

However one final point is that 'method' really only applies to
functions inside a class. Unbound functions inside a module are
just plain old functions.

It comes from the concept that each object has some method of
responding to a message. Which method may or may not be bound
to a "function". For example:

>>> class C:
...   def abc(s): print "ABC"
...
>>> o = C()
>>> o.abc()
ABC
>>> o.xyz()
<Traceback message here>

So the object o has a method for responding to abc() which prints
a message and a method for responding to xyz() which raises an
exception. Only one method is implemented as a bound function
in the class.

Alan G
(In nit picking mood!)




More information about the Tutor mailing list