On Thu, 30 May 2002, Patrick K. O'Brien wrote:
Without trying to open a can of worms here, is there any sort of consensus on the use of packages with multiple smaller modules vs. one module containing everything? I'm asking about the Python standard library, specifically. According to the one-class-per-module rule of thumb, there are some Python modules that could be refactored into packages. Weighing against that is the convenience of importing a single module.
I'm just wondering if there are any guidelines that should frame one's thinking beyond the fairly obvious ones? For example, is the standard library an exceptional case because it must appeal to new users as well as experts? Does a good part of this issue come down to personal preference? Or are there advantages and disadvantages that should be documented? (Maybe they already have.)
Is the current library configuration considered healthy? There are a mix of packages and single modules. Are these implementations pretty optimal, or would they be organized differently if one had the chance to do it all over again?
Interesting question! Python Style Guide doesn't tell much about this. I think that if there is (more or less) natural hierarchy, then monolith module is better to partition into smaller ones. For example, os module. Even docs are mentioning 4 aspects of it. But only os.path is (kinda) separate. os.fd could have their own, as well as os.proc os.fs ... This way they are remembered better... xml-packages is another good example. Otherwise there is no point in adding hierarchy in standard libs. I think, modularizing is very similar to constructing good object class hierarchy. With the main fear - not to overdesign it. Sincerely yours, Roman Suzi -- \_ Russia \_ Karelia \_ Petrozavodsk \_ rnd@onego.ru \_ \_ Thursday, May 30, 2002 \_ Powered by Linux RedHat 7.2 \_ \_ "How do I love thee? My accumulator overflows." \_