Application-global "switches"?

[kj]

I'm looking for the "best-practice" way to define application-global
read-only switches, settable from the command line. The best
example I can think of of such global switch is the built-in variable
__debug__. This variable is visible everywhere in a program, and
broadly affects its operation.

The situation that prompts this question is the task of implementing
a certain application that is supposed to run for several days
(typically 2-3 weeks). It is important to be able to re-start this
application where it left off in case that, for some reason (e.g.
internet connection failure), it terminates prematurely. When this
application is restarted its behavior is somewhat different from
when it is started from scratch. (For example, when it is re-started,
it does not clear certain directories.)

Hence, I'd like to be able to have a variable, e.g. CONTINUATION_MODE,
visible everywhere in the code, that tells the application to behave
in "continuation mode", so that I can write stuff like

if not CONTINUATION_MODE:
clean_the_slate()

The only solution I can come up with is to define a "dummy module",
say _config.py, which contains only upper-case variables representing
these global switches, and is imported by all the other modules in
the application with the line "from _config import *". During the
early stages of the run, the script inspects the command-line flags,
and if it finds a --continuing flag, it sets the variable
_config.CONTINUATION_MODE to True. (The last point implies that
these variables are not strictly speaking read-only, since they
most be set at the beginning of the run. But after this initial
setting, they should remain read-only.)

I'm sure this would work OK, but I wonder if there is a more Pythonic
way to do this sort of thing. Is there a best practice for setting
such application-global switches?

TIA!

kynn

[Terry Reedy]

I believe what you describe above is more or less standard practice.

[ici]

while 1:
try:
run_main_code()
cleanup()
except:
while conn_fail():
time.sleep(5.0)
finally:
cleanup_all()

[Ethan Furman]

How will this restart the OP's process with all files still in place and
continuation mode on?

~Ethan

[Ethan Furman]

I've seen a couple cool recipes implementing WORM* attributes if you
wanted to ensure that your settings were not re-set.

Steven D'Aprano wrote one with a class name of ConstantNamespace, you
can search on that if you're interested. I'd include the code, but I
have no idea if that's good netiquette or not.

~Ethan~

*Write Once Read Many, for those unfamiliar with the term

[kj]

In <mailman.996.1252128...@python.org> Ethan Furman <et...@stoneleaf.us> writes:

>I've seen a couple cool recipes implementing WORM* attributes if you
>wanted to ensure that your settings were not re-set.

>Steven D'Aprano wrote one with a class name of ConstantNamespace, you
>can search on that if you're interested. I'd include the code, but I
>have no idea if that's good netiquette or not.

Thanks, I'll check this out.

kynn

[Nick Craig-Wood]

kj <no.e...@please.post> wrote:
> I'm looking for the "best-practice" way to define application-global
> read-only switches, settable from the command line. The best
> example I can think of of such global switch is the built-in variable
> __debug__. This variable is visible everywhere in a program, and
> broadly affects its operation.

This is what I've done in the past...

Create a Config class in a module called config.py and instantiate it

class Config:
def __init__(self):
self.debug = True
# etc

config = Config()

Then where you want to use it you can then use

from config import config

if config.debug:
# blah

This has the advantage that you can define some methods on your config
object (eg save).

I don't know whether this is best practice but it works for me!

--
Nick Craig-Wood <ni...@craig-wood.com> -- http://www.craig-wood.com/nick

[Marius Gedminas]

On Sep 4, 9:29 pm, kj <no.em...@please.post> wrote:

> The only solution I can come up with is to define a "dummy module",
> say _config.py, which contains only upper-case variables representing
> these global switches, and is imported by all the other modules in
> the application with the line "from _config import *".  During the
> early stages of the run, the script inspects the command-line flags,
> and if it finds a --continuing flag, it sets the variable
> _config.CONTINUATION_MODE to True.  (The last point implies that
> these variables are not strictly speaking read-only, since they
> most be set at the beginning of the run.  But after this initial
> setting, they should remain read-only.)

Be very very careful about "from _config import *". If you import
a module that, in turn, imports _config this way, before you set
the initial values, that module will already have made its own copies
of all the variables and thus will not see the correct values.

[kj]

In <579a15bf-83c0-4228...@o13g2000vbl.googlegroups.com> Marius Gedminas <mge...@gmail.com> writes:

>On Sep 4, 9:29=A0pm, kj <no.em...@please.post> wrote:
>> The only solution I can come up with is to define a "dummy module",
>> say _config.py, which contains only upper-case variables representing
>> these global switches, and is imported by all the other modules in

>> the application with the line "from _config import *". =A0During the

>> early stages of the run, the script inspects the command-line flags,
>> and if it finds a --continuing flag, it sets the variable

>> _config.CONTINUATION_MODE to True. =A0(The last point implies that

>> these variables are not strictly speaking read-only, since they

>> most be set at the beginning of the run. =A0But after this initial

>> setting, they should remain read-only.)

>Be very very careful about "from _config import *". If you import
>a module that, in turn, imports _config this way, before you set
>the initial values, that module will already have made its own copies
>of all the variables and thus will not see the correct values.

Good point. That's another reason for going for something like
Nick's solution earlier in this thread.

Thanks,

kynn