[Python-Dev] Re: Adding Optik to the standard library

[Roman Suzi]

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." \_