[Tutor] Philosphy on method naming in modules?

[Jeff Shannon]

Terry Carroll wrote:

> So here's the thing: should the developer of a module that's going to be 
> publicly shared try to use unique method names, to avoid name collisions 
> with other modules?  For example, a method I have that uses Tkinter to 
> display the character and its related data is named merely "Display."  
 > [...]
> 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" or "from 
> foo import *" to import; so I usually end up fully-qualifying the method 
> names I use, anyway (the exception being Tkinter, where the code just bogs 
> down too much).

The way you're using modules is the *safe* way to use modules.  Anyone 
using one of the other mechanisms, especially 'from foo import *', 
should know that they are doing something that's risky and may cause 
namespace collisions.

In general, I feel that there's too many modules out there for it to 
be practical to deliberately choose different names.  The whole point 
of using module namespaces is to uniquely qualify a name; adding an 
additional unique prefix (or whatever) seems redundant.

Note that some modules are designed to be imported into the current 
namespace, and they *do* take care to try to avoid collisions with 
built-in names.  But even there, they don't tend to work too hard to 
avoid collisions with names in other third-party packages -- there's 
too many for that to be practical.

In short, I think the way you're doing it is fine, and you should 
continue as-is.

Jeff Shannon
Technician/Programmer
Credit International