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. -- https://mail.python.org/mailman/listinfo/python-list
