Sort of tired of long constant names – Bunch to the rescue!
I’ve gotten a little bit tired of long constant names, like imagine there’s constants.py module which has the following:
MESSAGE_CREATE_FOO = '1000' MESSAGE_DELETE_FOO = '1001' # And so on..
Now the trouble is with importing it all. I can do either:
from constants import *
Which may be considered a bad style on one hand and on the other hand it becomes a mess if your IDE, like Wing IDE, autocompletes the names for you, so you type ME and then have to scroll through several dozens of them. Not to mention that it’s hardly ever the case that all of the constants are needed in any single module.
I can also carefully pick the names I need, like so:
from constants import MESSAGE_CREATE_FOO, MESSAGE_DELETE_FOO # And so on..
But that’s yet another place that needs to be kept in sync with the rest of the code.
So I’ve finally settled on using the Bunch class, which basically is a regular dictionary with an extra attribute-style access, meaning I can now write it all like so:
from bunch import Bunch MESSAGE = Bunch() MESSAGE.CREATE_FOO = '1000' MESSAGE.DELETE_FOO = '1001' # And so on..
# Yay, we're importing one thing only, the only one needed # in this module, and if the code below ever starts deleting # FOO, we won't have to update the import statement! from constants import MESSAGE print(MESSAGE.CREATE_FOO)
Isn’t that nicer? 
Couldn’t you just create constants/MESSAGE.py with
CREATE_FOO = '1000'
DELETE_FOO = '1001'
and an empty constants/__init__.py
Then it works the same way, but you haven’t added a dependency
from constants import MESSAGE
print MESSAGE.CREATE_FOO
@Toby
Hi Toby!
Sure, that’s also fine. But given that Bunch is essentially a dict, it’s also trivial to convert the values to keys (to answer the questions along the lines of ‘which message does the 1821 code belong to`) and do all the other things dicts allow one to do.
In other words, I’ve no problems with that particular dependency, wouldn’t even mind it if it some day landed in stdlib!
Well ….
>>> import this
The Zen of Python, by Tim Peters
…
Flat is better than nested.
Readability counts.
…
There should be one– and preferably only one –obvious way to do it.
Although that way may not be obvious at first unless you’re Dutch.
…
Namespaces are one honking great idea — let’s do more of those!
@jul
Heya jul!
I’m not sure how that comment’s related to the post (if you’re saying that bunches are too flat or nested, whether I increased or did away with the readability, or what I’m doing is not obvious) but certainly I wholeheartedly agree with the Zen.
Thanks for stopping by!
I wonder why you need this Bunch module, you could just use a class:
in file message.py:
class MESSAGE(object): pass
MESSAGE.CREATE_FOO = 1
MESSAGE.DELETE_FOO = 2
in your program:
from message import MESSAGE
print MESSAGE.CREATE_FOO
@shi
Hello shi!
That will sure do the trick as well. Iterating over the attributes to build the code-to-message dictionary is a bit tiresome then but surely doable.
Thanks for the comment!
I did not know about Bunch, so thanks for the article.
“on the other hand it becomes a mess if your IDE, like Wing IDE, autocompletes the names for you, so you type ME and then have to scroll through several dozens of them”
This indicates a rookie IMHO. Turn off the “hints” option as it is only for the “keyboard challenged”. You can easily key in the name in less time and effort than it takes to get it from a hints menu, even if there are only one or two options. Also, it’s irritating to have a popup block some of the code if/when you want to check something again before finishing that if statement.
Following up on what Shi wrote… you might want to look at
http://pythonconquerstheuniverse.wordpress.com/category/python-features/globals-and-containe
rs/
and especially the first post in the series:
http://pythonconquerstheuniverse.wordpress.com/2010/10/20/a-globals-class-pattern-for-python/
@Joe
> I did not know about Bunch, so thanks for the article.
Sure thing Joe, the little class is really useful, give it a try!
> This indicates a rookie IMHO.
Heh, to each his own I’d say. I see no sign of rookieness in that
@Steve Ferg
Thanks for the links Steve, these look truly idiomatic in the general case, fully agreed.
Only that in my particular case it’s still not that handy when there’s a need for frequently iterating over the constants.
Cheers!