Classes as namespaces?
in [Python]
|
From: Jonathan Hartley on 27 Mar 2010 07:28 On Mar 26, 6:26 pm, Luis M. González <luis...(a)gmail.com> wrote: > 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... 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?
From: J. Clifford Dyer on 27 Mar 2010 07:54 On Sat, Mar 27, 2010 at 04:28:56AM -0700, Jonathan Hartley wrote regarding Re: Classes as namespaces?: > > 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? > -- > http://mail.python.org/mailman/listinfo/python-list Hmm. I don't like that because it leaves a class polluting your namespace that doesn't behave like a class. Using a function for that purpose doesn't seem as bad, because even if you don't call it again, at least you *could*, and it would behave in an expected fashion. If you're dead-set against calling the chunk of code you just created, and you're using python 2.5 or higher, you might consider creating a no-op context manager: x = 1 with code_block("Account for non square pixels"): ((complex_logic)) y = 2 Though in general, I think refactoring your code to reasonably scoped functions or methods is a better idea. If it's too complex to read in one block, it's probably too complex for one function.
From: J. Clifford Dyer on 27 Mar 2010 08:04 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. I would also not rule out letting your "pseudo-namespace" grow into a full-fledged class. If you've got a method that makes sense with your class, use it. class Cfg(object): spam = object() jambon = object() huevos = object() def get_animal(self, meat): if meat == self.jambon: return 'pig' elif meat == self.huevos: return 'chicken' elif meat = self.spam: return 'spamalope' Later, perhaps, you might refactor so that each meat type (OK so huevos aren't a meat) gets its own subclass, with a simple, one-line get_animal method. Cheers, Cliff
From: Steve Holden on 27 Mar 2010 08:22 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) >> [...] > 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. > It also has the advantage (?) that you can use "is" (identity) comparisons rather than testing for equality, though this is only a readability issue, I suspect. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
From: Philip Semanchuk on 27 Mar 2010 09:26
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 |