tags:

views:

187

answers:

6
+4  Q: 

Python Constants

I have done searches on Google and here at Stackoverflow but can not find what I am looking for.

I am relatively new to Python. I looking to create a "settings" module where various application specific constants will be stored.

Here is how I am wanting to setup my code

settings.py

CONSTANT = 'value'

script.py

import settings

def func():
    var = CONSTANT
    --- do some more coding ---
    return var

I am getting a Python error stating: "global name 'CONSTANT' is not defined.

I have noticed on Django's source code their settings.py file has constants named just like I do. I am confused on how they can be imported to a script and referenced through the application.

EDIT

Thank you for all your answers! I tried the following:

import settings

print settings.CONSTANT

I get the same error: ImportError: cannot import name CONSTANT

A: 

Leave your settings.py exactly as it is, then you can use it dust as Django does:

import settings

def func():
    var = settings.CONSTANT
Ned Batchelder
+8  A: 

The easiest way to do this is to just have settings be a module.

(settings.py)

CONSTANT1 = "value1"
CONSTANT2 = "value2"

(consumer.py)

import settings

print settings.CONSTANT1
print settings.CONSTANT2

When you import a python module, you have to prefix the the variables that you pull from it with the module name. If you know exactly what values you want to use from it in a given file and you are not worried about them changing during execution, then you can do

from settings import CONSTANT1, CONSTANT2

print CONSTANT1
print CONSTANT2

but I wouldn't get carried away with that last one. It makes it difficult for people reading your code to tell where values are coming from. and precludes those values being updated if another client module changes them. One final way to do it is

import settings as s

print s.CONSTANT1
print s.CONSTANT2

This saves you typing, will propagate updates and only requires readers to remember that anything after s is from the settings module.

aaronasterling
+1 made my answer obsolete
delnan
@delnan I specifically avoided mentioning the mechanics so as to not make your answer obsolete ;)
aaronasterling
Well, practically obsolete ;) Knowing the exact semantics is useful and preferable, but to make it work, it's not needed - though it is necessary to know the implications of it, which are pretty much summarzied in your answer.
delnan
I though the idea of constant is that it cannot be changed on runtime?
Lie Ryan
@Lie Ryan, Python doesn't have constants. On multiprogrammer projects, you never know.
aaronasterling
@AaronMcSmoot: yes, but if you even have the intention to change a constant after runtime, that's very suspect that you've got the wrong design.
Lie Ryan
@Lie Ryan. I'm not sure that I entirely agree. 'setting' is a more accurate term than 'constant' in python and why can't settings change so long as all client code is aware of it? Regardless though, the fact that it's a possibility means that it should be taken into account
aaronasterling
@AaronMcSmooth: settings != CONSTANTS. Changing constants at runtime does not make sense. IMO, if you take into account the possibility of changing a constant, then you're overdesigning. OTOH, settings are meant to be changed on runtime; but settings shouldn't use ALLCAPS, otherwise you're nullifying the advantage of having constants written in ALLCAPS.
Lie Ryan
@Lie Ryan. about the overdesign. When the only thing that i'm advocating is that those changes (if they occur) propagate, then I don't think that's overdesign. Especially not if it dovetails with what is otherwise a best practive, such as avoiding barenames. It makes mocking for tests easier, for instance.
aaronasterling
@AaronMcSmooth: what I'm trying to say is, that those changes should not happen at all. If there is a change in the value of a constant, then it's a bug; either in the design or in the program itself. Why would you want to have a different constant values when testing? They should never change, period. You should never assign to an ALLCAPS name, except once when declaring the constant. There is no need to design it for the possibility of changing it.
Lie Ryan
+1  A: 

When you import settings, a module object called settings is placed in the global namespace - and this object carries has that was in settings.py as attributes. I.e. outside of settings.py, you refer to CONSTANT as settings.CONSTANT.

delnan
A: 

...Or, if you really want all the constants from settings.py to be imported into the global namespace, you can run

from settings import *

...but otherwise using settings.CONSTANT, as everyone else has mentioned here, is quite right.

ewall
See my answer for all three possible ways to use the `import` statement.
aaronasterling
Actually, this is not advisable. See e.g. http://docs.python.org/howto/doanddont.html#from-module-import. Although in this case it has the propably desirable side effect that changes to the constants won't affect other modules.
delnan
Nicely said, @AaronMcSmooth. And technically I didn't say it was advisable to import *, just that it was possible :P
ewall
@delnan. I'm not so sure that that's desirable. It depends on the application but It could just as likely be that changes should be propagated (if they even occur)
aaronasterling
A: 

Try this:

In settings.py:

CONSTANT = 5

In your main file:

from settings import CONSTANT

class A:
    b = CONSTANT

    def printb(self):
         print self.b

I think your above error is coming from the settings file being imported too late. Make sure it's at the top of the file.

kcunning
A: 

See the answer I posted to Can I prevent modifying an object in Python? which does what you want (as well as force the use of UPPERCASE identifiers). It might actually be a better answer for this question than it was for the the other.

martineau