__module__ (was Re: Deprecate self)

Alex Martelli aleaxit at yahoo.com
Fri Apr 20 17:24:47 EDT 2001


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


> > That there exist design situations where a single copy of a
> > certain "state" is desirable, is hardly in question -- that IS
> > a force that comes up again and again.  The issue is how to
> > best resolve it, and the other forces that accompany it in
> > various use cases.
>
> 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.


> > > Python is more than complex enough for me.
> >
> > So how would __module__ and __istance__ and __function__
> > and all other such additions REDUCE its complexity that
> > you perceive?
>
> 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.


'global' does (in my modest experience) give some problem
to some students, typically coming out as expressions of
astonisment that some equivalent of

x=23
def f():
    print x
    x=45
    print x

fails.  This empirical observation does lend some support to
your thesis.  However, I wonder if having the 'fix' be changing
the assignment to "__module__.x=45", rather than inserting
a "global x", would do all that much good in this regard.


Alex






More information about the Python-list mailing list