Import order question

Wed Feb 19 08:28:50 EST 2014

In article <53045df20ドル2788ドル$c3e8da3$76491128 at news.astraweb.com>,
 Steven D'Aprano <steve at pearwood.info> wrote:
> How do you know that the module tk_optionmenu.py contains the class 
> OptionMenu? Perhaps it contains the function optionmenu. Or the class 
> TK_OptionMenu. 

Stuff like this is a really important issue once a codebase gets large 
enough that nobody has it all memorized. If I'm looking at a piece of 
code:
 foo = Frobnicator()
 foo.flamozilate()
and I want to get a better understanding of what flamozilation involves, 
it saves me a bunch of time if I can look at the class name and guess 
where it lives. Otherwise, I'm reduced to:
$ cd $BASE_DIR; find . -name '*.py' | xargs grep "class Frobnicator"
In the Songza codebase, we often deal with triples of related names. A 
class FooBar should live in a file models/foo_bar.py, and the name of 
the related database collection (think: SQL table name) should be 
"foo_bar". When any of those assumptions are broken (and, sadly, 
sometimes they are), the cost of maintenance goes up.
Sometimes we'll put a small collection of very closely related classes 
in one file. So, FrobnicatorIndexHelper would probably be in the same 
file as Frobnicator.
I once worked on a huge C++ project that had thousands of classes spread 
out over about 50 modules. They had adopted the convention that *every* 
class name was something like CI_Frobnicator; the prefix told you where 
the class lived.