Classes as namespaces?

[Gregory Ewing]

What's the word on using "classes as namespaces"?

My only concern would be that classes do magical things with certain
types when you retrieve them as attributes (e.g. functions, property
descriptors), so you can't use one as a completely general purpose
transparent container. But for enum constants and the like this
isn't a problem.

If you're up for a bit of hackery, the following code tricks the
class statement into producing a module instead of a class:

from types import ModuleType

class MetaNamespace(ModuleType):

def __init__(self, name, bases, dict):
ModuleType.__init__(self, name)
self.__file__ = __file__
self.__dict__.update(dict)

Namespace = MetaNamespace.__new__(MetaNamespace)

class Foo(Namespace):

ford = 42
arthur = 88

print Foo
print Foo.__dict__

 

[Raymond Hettinger]

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)

Works for me.


Raymond

 

[News123]

Hi STephen,

That said...

[*] 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.). Here I find myself on the opposite side of the purist/pragmatic
divide. Hmmm.

What?!

Where do you get this "widespread practice"? You mentioned that before
when you last posted about that and I forgot to comment. I've never seen
it.

I wouldn't say it's wide spread, but definitely something one
encounters. Especially with python rather new to python

In the 110k lines of in-house code I maintain, we don't use it once; we
have somewhere around 300k lines of third-party code from a wide range
of sources, and although I haven't reviewed it all by any means, I
regularly have to peek over it and I never seen triple quoted "comments".

Hell, I almost never see commented -code-. Code should only be commented
while fiddling or debugging. Once fiddlng is done, dead code should be
removed.

I'm sure it -happens- every once in awhile, but.. why? Who uses editors
that can't block comment/uncomment anymore?

I had to explain block comment / uncomment to some collegues before the
triple quote commenting disappeared from our code.
Unfortunaltely everybody uses a different type of editor, so I googled
for them to show them what their editors can do.

You'd be surprised how many people do neither master their editors nor
care for it.

bye

N

 

[Lie Ryan]

one might like to name the complex block of logic, just to make it
readable:


x = 1
def account_for_non_square_pixels(x):
((some complex logic))
account_for_non_square_pixels()
y = 2


But defining and then calling the function like that is a tad
cumbersome. So I was wondering about:

I never liked the narrow definition of function as "reusable piece of
code". This narrow definition implies that a piece of code used only
once do not need to be made a function.

I would rather define function as "a logically independent piece of
code" and encourage refactorizing code into functions even if they are
only used once as long as they are conceptually a "step" and being able
to reuse code as a nice side-effect of it.

Under this definition, the "some complex logic" conceptually is an
independent piece of code that can (and probably should) be factorized.

 

[Aahz]

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)

There is one gotcha associated with using classes as namespaces: you have
to be careful to avoid instantiating them. That goes triple if you
modify the class attributes, because modifying an attribute in an
instance does *not* propagate the change to the class.

 

[Bruno Desthuilliers]

Aahz a écrit :

There is one gotcha associated with using classes as namespaces: you have
to be careful to avoid instantiating them. That goes triple if you
modify the class attributes, because modifying an attribute in an
instance does *not* propagate the change to the class.

This can be "solved" (using only classmethods and overriding
__setattr__), but then it begins to be a bit OOTP for a mostly simple
usecase.