Import order question

[Rick Johnson]

On Tuesday, February 18, 2014 3:02:26 PM UTC-6, Chris Angelico wrote:
> On Wed, Feb 19, 2014 at 7:41 AM, Rick Johnson wrote:
> >     # ui_main.py
> >     from ui_mod1 import *
> >     from ui_mod2 import *
> >     from ui_mod3 import *
> >     from ui_mod4 import *
> > At least by this method i can maintain the code base without
> > wearing-out my scroll finger and eventually loosing my mind.
> > THE MORAL: With very few exceptions, please put EVERY class
> > in it's own module.
> Absolutely definitely not. If you're going to import * into every
> module, just write it all in a single source file.

Writing multiple individual classes in multiple individual
modules, and then importing those individual classes under a
single namespace at run-time is key to exposing a monolithic
API to a client without storing all the source code in a
monolithic file. The "Tkinter" folks would be wise to follow
my advise!

But I'm not suggesting this is the solution to EVERY
problem, or even that this is the solution to the OP's
current problem, what i am suggesting is that source files
should be kept as short as possible so as to accommodate easy
maintenance.

You see, unlike other languages, Python does not give us a
choice of the start and end of a Python module, there is no
keyword or delimiting chars that we can use to EXPLICITLY
define the start and end of a Python module. No, EVERY
Python script IS a module by default, and that is the law of
the land.

> Otherwise, when
> someone tries to find the source code for some particular class or
> function, s/he has to go digging through all five source files - first
> the utterly useless merge-point, then the four others, because there's
> no way to know which one has it.

Only if you're blind, or your source code was written by
people lacking even a modicum of common sense about how to
name a module. Most modules can simply be the name of the
containing class. Heck, even an idiot can manage that!

> Python could make this easier for us, by retaining the origin of every
> function and class. And maybe it's already there, but I don't know
> about it.

Google "inspect" and be enlightened. But Chris, if you have
to use the inspect module to find a class then sir, you need
lack: simple search tools, and/or motivation.

Are you telling me you're willing to search through a single
file containing 3,734 lines of code (yes, Tkinter) looking
for a method named "destroy" of a class named "OptionMenu"
(of which three other classes contain a method of the same
exact name!), when all you needed to do was open one single
module named "tk_optionmenu.py" and do a single search for
"def destroy"?

You must be trolling!

> But even if it did exist (by the way, it would be useful for
> other things than just taming a mad layout like this), it'd still be
> better to keep everything combined, because the origin of a
> function/class could just as easily go to the exact line as to the
> file.
> A module is a namespace. It should be used as such. If you want a
> package, use a package. There's no point putting each class out
> separate unless you really need that.

But in many cases you do! Chris, i think you missed the
entire crux of this thread. The OP is not writing a single
monolithic program where the code will ONLY be investigated
by the developers, no, he's creating an API, and API's
require structure.

But even if this were not an API, breaking large chunks of
code up and spreading them across individual files is the
key to managing code bases.