New PEP: Quality Guidelines For Standard Modules
Carlos Ribeiro
cribeiro at mail.inet.com.br
Mon Jul 2 07:55:10 EDT 2001
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
More information about the Python-list
mailing list