Well, I'd hardly point to C++ as an ideal ;-), but...
I work at a C++ shop with a huge framework-- 3K classes,
~15 levels of inheritance, multiple inheritance, etc. We
organize code by following the simple rule of 1 class per
source file: for each class, there's a '.C' and a '.h'
file. Since everything we do is structured as classes,
this is easy to do, and makes finding code simple.
In Python, this would mean 1 'class' statement per module,
and the module file's name would be the same as the class's.
Of course, there's exceptions:
> Are there any good guidelines as to
> when a method should be in a class, rather than a module ...
Everything related to the object type should probably be
in the class itself; this is just basic OOP style. But
things that have no implied object can be collected in
modules that associate related 'object-less' things.
In C++-land, we make a dummy class with all its methods
'static' for such things, to emulate Python's module name-space
partitioning; C++ scope-qualifiers are used to access the
static methods/data [a C++ poor-man's module :-)]. And each
of these classes has 1 source file.
Of course, I'm among those most opposed to coding standards
in general, and this is very much a matter of personal style!
But 1-module-per-class, with a few modules of non-object
functions, seems to work in a heavily OOP environment.
OTOH, structures that work for a static, compiled language
like C++ may not apply to a language like Python...
YMMV,
Mark L.