On Tuesday 13 September 2005 12:46 pm, George Sakkis wrote: > "Terry Hancock" <[EMAIL PROTECTED]> wrote: > > On Monday 12 September 2005 10:09 pm, [EMAIL PROTECTED] wrote: > > > I like to keep my classes each in a separate file with the same name of > > > the class. > > Apparently "foo" is already a package defined using __init__.py, > > so you know about that part already. > > > > Just change its contents to read: > > > > from Bar import Bar > > from Blah import Blah > > from Zzz import Zzz > > If you do this often or have lots of classes you want to import this > way, you could automate it:
(nice) > [...] > Or even better, forget about the braindead java restriction of one > class per file and organize your code as it makes more sense to you. While this is good sound Python advice, there are good Human-readability reasons for keeping a small number of classes per module. Python classes certainly may not tend to blossum into the verbosity of their Java counterparts, but I've still seen some pretty chunky classes (e.g. in the Zope sources). So, the __init__.py approach and packaging is still a good idea. I particularly like the ability of __init__.py to craft the interface layout of the module, independently of the file-structure that you choose, as the best layout for the user may not be the best layout for the developer. I personally wouldn't favor automating this process unless you are actually working with some kind of "plugin" design pattern. It's nicer to have the fine control over the interface and be able to pick and choose how things should be laid out. And the __init__.py code then serves as a map for the developer to figure out where things are stored (yes, they could also use grep, but every little bit helps). -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
