In article <53045df2$0$2788$c3e8da3$76491...@news.astraweb.com>,
Steven D'Aprano <st...@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.
--
https://mail.python.org/mailman/listinfo/python-list
