[Tutor] Re: Philosphy on method naming in modules?

[Andrei]

Terry Carroll wrote:
<snip>
> 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."  
<snip>
> 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).

"from something import *" is bad form in Python and this I suppose is 
one of the reasons :).

> So what do you guys think?  For an unbound method to display a thing, 
> should you use a nice generic name like "Display", or deliberately alter 
> the name to something a little less mnemonic, but less likely to collide 
> (say, "UnihanDisplay", "UHDisplay" or some such)?

I for one would call it something meaningful (Display isn't really 
descriptive IMO, especially if it's a function, not a class method - but 
then again, I haven't seen the module, perhaps the name says it all in 
your case). When you call it something descriptive, chances of overlap 
are pretty low. On the other hand, I wouldn't screw up the name 
especially in order to make it less likely to collide (the important 
thing is to have an unique module name). On a sidenote, I for one also 
prefer "displayUnihan" (verb first and starting with a lowercase), but 
this is very much a matter of taste I suppose. I'd also avoid UHDisplay 
because it's hard to type and remember - doubly so since Python is case 
sensitive.

Andrei



=====
Mail address in header catches spam. Real contact info (decode with rot13):
cebwrpg5 at bcrenznvy.pbz. Fcnz-serr! Cyrnfr qb abg hfr va choyvp cbfgf. V 
ernq gur yvfg, fb gurer'f ab arrq gb PP.