__module__ (was Re: Deprecate self)

[Rainer Deyke]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:9bq9ir01lad at news1.newsguy.com...
> "Rainer Deyke" <root at rainerdeyke.com> wrote in message
> news:a8_D6.60935$J%5.20446933 at news2.rdc2.tx.home.com...
>     [snip]
> > Just as I can use the term "command" to refer something different from
the
> > Command design pattern (note different capitalization), I generally use
> the
> > word singleton to refer to something that is not necessarily implemented
> > through the Singleton design pattern.
>
> Makes sense, which is why I asked very specifically, when you
> mentioned singletons, whether you had examples where you
> found the Singleton design pattern best.  Apparently your
> answer was not to the question I asked.

To answer your question, I have yet to use either the Singleton pattern or
the Flyweight pattern exactly as described in Design Patterns.  To
enapsulate global state I use global variables (or, in C++, static variables
of functions).  Sometimes these variables require a new class, usually they
don't.

> > What generic word would you use to refer to an object that encapsulates
> > program-wide unique state?
>
> As it happens, in my favourite (free-time) application area, I had
> better avoid naming such object 'singletons' any more than I could
> name others 'doubles', 'diamonds' or 'squeezes' -- these are all
> important words and concepts in contract bridge (and, some of
> them, in other games, too -- but bridge is my field).
>
> Apart from application areas -- in maths, a singleton is a set with
> a single member... it's not that member (and the distinction is
> important).  If one looks at a _class_ as somehow equivalent to
> the set of its instances, then calling the *class* 'a singleton' may
> make sense, but calling the *instance* 'a singleton' would not.

This does not answer my question.

> > See above for my Grand Unification Scheme.  '__module__', at least,
makes
> > 'global' redundant.  As I stated in another thread, sometimes you need
to
> > add new features before you can remove old ones.  '__module__' seems
> simpler
> > to me than the one-and-only non-executable statement in Python.
>
> If modifying globals from inside a function is meant to be a rare
> thing, then I agree with you that using "__module__.x=y" &c for
> such modifications (rather than "global x" followed by "x=y") may
> be perfectly acceptable.  The global statement does cater better
> for a style in which such "rebinding of globals" from within a
> function come "in clusters" -- many functions may not need to
> do any such binding, but those that do may need to bind more
> than one global or at least bind a global in several places, e.g.
>
> def example():
>     global x,y,z
>     if x>0:
>         x=y=z=23
>     elif y<z:
>         x=y=z=34
>
> is already substantially more readable than an equivalent
> using __module__ six times.

The same argument could apply to methods:

def example(self):
  if self.x > 0:
    self.x = self.y = self.z = 23
  elif self.y < self.z:
    self.x = self.y = self.z = 34

vs.

def example(self):
  instance x, y, z
  if x > 0:
    x = y = z = 23
  elif y < z:
    x = y = z = 34


I find the former quite readable, but that's just me.  If you recall, I was
arguing for consistency, not necessarily for any specific approach.


--
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games           -           http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor