Classes as namespaces?

[Philip Semanchuk]

On Mar 27, 2010, at 8:04 AM, J. Clifford Dyer wrote:

> On Fri, Mar 26, 2010 at 02:49:02PM +0000, kj wrote regarding Classes  
> as namespaces?:
>>
>> 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.
>>
>> 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
>
> I don't see anything wrong with this, except that I would clean it  
> up in a couple ways.  Like other posters, I would give the class a  
> proper class name (Cfg).
>
> I also would not assign integers to spam, jambon, or huevos.   
> Instead I would assign each a bare object().  That way you won't get  
> unexpected interactions with other constants outside the class.  An  
> object() is equal only to itself.

What I like about this method is that it will break the bad habit I  
see in junior programmers of making assumptions about the value of the  
constant. For instance, if they see that Cfg.JAMBON = 3 and hardcode 3  
in their code somewhere, that will work fine until someone re-orders  
the constants. Using object() instead forces them to use Cfg.JAMBON  
since the value will (probably) change with every run of the program.

It will also discourage bugs-waiting-to-happen like this:
if breakfast > Cfg.SPAM:
     print "Good news, breakfast is jambon or huevos"



bye
P