Import order question

[Roy Smith]

In article <53045df2$0$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.