[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Classes as namespaces?

kj

3/26/2010 2:49:00 PM



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

[*] 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.
23 Answers

Harishankar

3/26/2010 3:04:00 PM

0

On Fri, 26 Mar 2010 14:49:02 +0000, 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.
>
> 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
>
> [*] 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.

I myself am a humble beginner in many ways, but generally isn't that
(namespacing) achieved by using modules?

I don't find the need generally to assign namespace to local variables
and when there is a need for it, module level objects do the job.

Philip Semanchuk

3/26/2010 3:09:00 PM

0


On Mar 26, 2010, at 10:49 AM, 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.
>
> 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?

I hope it's not problematic; I use it all the time.

A few differences about the way I do it:
- I respect PEP 8 for the class name (CamelCaps)
- If the attributes are supposed to be constants, I capitalize the
attributes
- I often add NONE with a value of zero so that bool(MyClass.NONE)
will evaluate to False and everything else will be True

Here's an example from my code:

class Apodization(object):
""" Apodization constants """
# These constants are arbitrary and may change.
# However bool(NONE) is guaranteed to be False
NONE = 0
GAUSSIAN = 1
LORENTZIAN = 2



Cheers
Philip

Jon Clements

3/26/2010 3:47:00 PM

0

On 26 Mar, 14:49, kj <no.em...@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)
>
> 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
>
> [*] 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.

Given this example, I would go for the module and CONSTANT_NAMING
approach.

But yes, even in the docs. you can use a class as a C type-of struct.

I stick to the convention of a class knows what it's doing,
what it's doing it on, and a module just happens to contain those
classes.

C++ std::algorithm for instance,
makes sense it's called std, ditto algorithm and has shed loads in it,
but would I create a class called algorithm (unlikely).

I would tend to view modules as "namespace". Rightly or wrongly, just
lets you make the right design choice.

Jon.

Jack Diederich

3/26/2010 3:49:00 PM

0

On Fri, Mar 26, 2010 at 10:49 AM, kj <no.email@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)

Classes as namespaces are a valid use case (I do it all the time).
Python 3 has a small cleanup that makes classes even closer to module
namespaces; namely the concept of "unbound methods" goes away. In
3.x when you get a function from a class you get the function itself
and not an unbound function.

-Jack

Jean-Michel Pichavant

3/26/2010 3:51:00 PM

0

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

kj

3/26/2010 5:52:00 PM

0




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.)

Philip Semanchuk

3/26/2010 6:11:00 PM

0


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

Luis M. González

3/26/2010 6:26:00 PM

0

On 26 mar, 11:49, kj <no.em...@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...

Steven D'Aprano

3/27/2010 12:04:00 AM

0

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

Jonathan Hartley

3/27/2010 11:29:00 AM

0

On Mar 26, 6:26 pm, Luis M. González <luis...@gmail.com> wrote:
> On 26 mar, 11:49, kj <no.em...@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...


Hey everyone. By coincidence, only yesterday I was wondering about
using classes as a way of labeling a block of code, ie. an lightweight
alternative to defining a function that would only be called from one
location.

eg. instead of:


x = 1
((some complex logic))
y = 2


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:



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


I don't exactly like this, but I think you can see what I'm getting
at. Does this fall down in some way I haven't grasped? Is it as awful
an abuse of 'class' as my intuition suggests it is? Is there a way to
do it better?