New PEP: Quality Guidelines For Standard Modules

[Carlos Ribeiro]

Let me try explain this topic a little bit better. I've highlighted more 
words this time:

      1. Standard Modules MUST not rely on global variables to keep
         state information, EXCEPT when it is ABSOLUTELY required.

Standard modules should not rely on global variables to store state. It 
makes more difficult to use the library functionality on different 
instances at the same time. It breaks the consistence rule, because you 
need to take extra care to avoid some constructs if the module uses 
globals. For instance, you can open as many files at you want at the same 
time (within the practical limits of your platform), but you aren't 
supposed to use more than one instance of the fileinput module. This 
limitation can and should be fixed - it's possible to do it using 
iterators, but I'm not still into 2.2, so I don't know for sure.

However, in some particular cases, it may be impossible to remove all 
global state information from the module. Some examples may include the use 
of specific features of the OS or the platform, that is global in its 
nature (path information is a good example). Then you have two choices: you 
either expose the global objects as part of the module interface (as it is 
the case with sys.path), or you expose it using a singleton class. I 
believe that using singletons makes it easier to use the module 
functionality in a flexible OO way.

Anyway, we can discuss why singletons are good and globals are not until 
the end of the universe. I just feel that using singletons will make things 
much more consistent with the OO paradigm that is used on most of the library.


Carlos Ribeiro