New PEP: Quality Guidelines For Standard Modules

[Steve Holden]

"Carlos Ribeiro" <cribeiro at mail.inet.com.br> wrote in message
news:mailman.994074843.3251.python-list at python.org...
> 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.
>
Carlos:

I don't think anyone is disagreeing with the sentiments you express. It's
simply that the word SHOULD is better (since it expresses your intended
meaning) than MUST ... EXCEPT.

MUST is usually used in standards and the like to indicate an absolute
requirement, without which an implementation would not be conformant.
Change MUST to SHOULD in the above and there would probably be no
dissenters.

Oh, sorry, this is c.l.py, there'll be some ;-)

Good effort, byt the way. I think we ("ordinary" Python users) have to put
some work in to underpin the foundations...

regards
 STeve

> 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
>
>
>