New PEP: Quality Guidelines For Standard Modules

[Carlos Ribeiro]

At 06:25 02/07/01 +0000, Courageous wrote:
>When writing language requirements, one MUST not use the
>term "MUST" in conjunction with an "except". And in any case,
>I disagree. Emphatically.

Point taken.

>The use of a singleton pattern changes nothing unless every
>call to the module has the singleton as its first argument. And
>if you're envisioning storing the singleton as a global, nothing
>has been accomplished. There's a global.
>
>Perhaps you could make a better case for why you think this
>is even important.

One example that comes to mind is the fileinput standard module. It stores 
global state:

input([files[, inplace[, backup]]])
Create an instance of the FileInput class. The instance will be used as 
global state for the functions of this module, and is also returned to use 
during iteration.


Let us say that you are iterating over the lines in the main loop of a 
filter, and then, depending on the line read, have to iterate over several 
other files. The global state prevents you from using the same instance of 
the fileinput module. The workaround is to import the module a second time, 
binding it by a different name. Please note that I haven't done any *real* 
test on this myself. Also, if the state variable is declared as a global, 
even reimporting the module will fail.


Carlos Ribeiro