Classes as namespaces?
in [Python]
|
From: Jean-Michel Pichavant on 26 Mar 2010 11:50 kj wrote: > What's the word on using "classes as namespaces"? E.g. > > class _cfg(object): > spam = 1 > jambon = 3 > huevos = 2 > > breakfast = (_cfg.spam, _cfg.jambon, _cfg.huevos) > > > Granted, this is not the "intended use" for classes, and therefore > could be viewed as a misuse ("that's what dictionaries are for", > etc.). But other than this somewhat academic objection[*], I really > can see no problem with using classes in this way. > You cannot see the problem because there's no problem using classes as namespaces. > And yet, I've come across online murky warnings against using > classes as "pseudo-namespaces". Is there some problem that I'm > not seeing with this technique? > > ~K > import this [snip] Namespaces are one honking great idea -- let's do more of those! Modules and dictionaries are no more namespaces than classes. So any container is potentially a namespace. JM
From: kj on 26 Mar 2010 13:51 Thanks for all your comments. I see that modules are arguably Python's standard way for implementing namespaces. I guess I tend to avoid modules primarily because of lingering mental trauma over incidents of insane/bizarro import bugs in the past. (It's not rational, I know; it's like when one develops an aversion for some previously liked food after a bout of food poisoning with it.) Now I postpone creating a new Python module until the pain of not doing so forces me beyond my phobia. (Yes, you got that right, I'm a basket case.)
From: Philip Semanchuk on 26 Mar 2010 14:10 On Mar 26, 2010, at 1:51 PM, kj wrote: > Thanks for all your comments. > > I see that modules are arguably Python's standard way for implementing > namespaces. I guess I tend to avoid modules primarily because of > lingering mental trauma over incidents of insane/bizarro import > bugs in the past. There can be good reasons (i.e. unrelated to trauma) not to use a one- namespace-per-module rule. For instance, The app I'm working on now has 43 classes defined in a constants.py file. Each class is just a namespace for constants. That's much more practical than 43 modules called foo_constants.py, bar_constants.py, etc. My Currency(type=CurrencyType.USD, value=decimal.Decimal(".02")), Philip
From: Luis M. González on 26 Mar 2010 14:26 On 26 mar, 11:49, kj <no.em...(a)please.post> wrote: > What's the word on using "classes as namespaces"? E.g. > > class _cfg(object): > spam = 1 > jambon = 3 > huevos = 2 > > breakfast = (_cfg.spam, _cfg.jambon, _cfg.huevos) I see no problem. I wouldn't mix English, French and Spanish in the same recipe though...
From: Steven D'Aprano on 26 Mar 2010 20:03
On Fri, 26 Mar 2010 14:49:02 +0000, kj wrote: > What's the word on using "classes as namespaces"? >>> import this [...] Namespaces are one honking great idea -- let's do more of those! > [*] My own subjective dislike for the widespread practice of using > triple quotes to comment out code is formally similar to this one ("the > 'intended use' for triple-quoting is not to comment out code", etc.). On the contrary. CPython deliberately strips bare strings (whether triple quoted or not) out during compilation. This isn't an accident, it is deliberate. >>> code = """ .... x = 1 .... y = 2 .... # comment .... "a string" .... z = 4 .... """ >>> o = compile(code, '', 'exec') >>> dis.dis(o) 2 0 LOAD_CONST 0 (1) 3 STORE_NAME 0 (x) 3 6 LOAD_CONST 1 (2) 9 STORE_NAME 1 (y) 6 12 LOAD_CONST 2 (4) 15 STORE_NAME 2 (z) 18 LOAD_CONST 3 (None) 21 RETURN_VALUE Why should you not do this? First, it is implementation-specific: other Pythons may not behave the same. Potentially they may compile in the (potentially large) string, push it on the stack, then immediately pop it off again. Older versions of CPython used to do that for non-strings. Secondly, and FAR more importantly, leaving large amounts of commented out code in your source is a TERRIBLE idea. Yes, sure, it's tempting to do, especially for quick and dirty scripts. Resist the temptation. Learn how to use a proper code repository. Don't leave the detritus of ancient unused code in your source files -- it confuses the reader, makes searching harder, slows down parsing, and (trust me) you will never need to read the old code again. It just gets in the way. Of course, like everything, this needs to be considered in context. You might leave commented-out code like this: # DON'T DO THIS: # s = spam(s, s*2) # It doesn't work. See bug #12345 in the tracker. Instead do this: s = spam(s*2, s) -- Steven |