__module__ (was Re: Deprecate self)

[Rainer Deyke]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:9bp9vl022jc at news1.newsguy.com...
> "Rainer Deyke" <root at rainerdeyke.com> wrote in message
> > def render(draw_fn):
> >   gc = get_gc()
> >   draw_fn(gc)
> >
> > def render_text(text):
> >   class Text:
> >     def __init__(self, text):
> >       self.text = text
> >     def draw(gc):
> >       gc.draw_text(self.text)
>
> I think you mean "def draw(self, gc):" here, right?  (Given
> that this is meant to be current-Python code).

Yes.  I still forget to explicitly list 'self' as an argument, even after
months of Python use.

> > defining module provides one instance and every instance other instance
is
> > identical in state and behavior.  Whether you call this a "Singleton" or
a
> > "Featherweight" or even "Gorak, destroyer of worlds" is all the same to
> me.
>
> Not to me, nor to most readers, since design patterns' _names_
> are an important characteristic -- the "primary key" used to
> retrieve (from memory, a book, etc etc) the various things that
> make up the pattern -- what forces it resolves, how, etc.  The
> Singleton DP goes to some effort to avoid multiple instantiation
> and relies on that; I've long thought that expending effort that
> is not greater, and in fact is often lesser, to ensure that
> multiple instantiations can occur innocuously (by sharing state
> among potentially-multiple instances), makes for better design
> patterns (albeit the catchy "Singleton" name makes it perhaps
> the most popular and well-known Gof4 DP).  So I'm always on the
> lookout for situations where the actual forces DO make Singleton
> preferable to FeatherWeight -- haven't found any so far.

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.

> 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?

> > My goal wasn't to change Python, but to discuss a perceived flaw in
Python
> > which later generations of language designers would then be able to
avoid
> > (or alternately to be convinced that the inconsistency is a good idea
for
> > pragmatic reasons).
>
> Your "strawman proposal" doesn't seem to show up any inconsistency in
> Python as it stands.

I consider classes/instances a special case of namespaces: one which allows
(multiple) instantiation and inheritance.  In actual pratice not all of the
classes I design are designed for multiple instantiation, or instantiation
at all for that matter.  What I would like to see is a separation of
concerns ("Does this namespace have __special__ attributes for operator
overloading?" inpdependent from "Does this namespace require
instantiation?") followed by a culling of irrelevant features ("Don't want
operator overloading?  Don't name your function '__add__' then.").  The
resulting programming language might look something like this:

namespace A: # Create a named unique object
  pass
namespace B(A): # Similar to 'from ... import', but done through linking
                # instead of copying
class C(A): # 'class' = namespace that requires/supports instantiation
            # class inherits from namespace => functions in namespace
            # are treated as "static" functions
  pass
namespace D(C()): # namespace inherits from instance of class
  pass


The module itself would be a 'namespace' object.  Overall, I think this has
the potential of creating a much simpler and more regular language.
Separate keywords for 'class' and 'namespace' might even turn out to be
unnecessary.

My pointing out the inconsistency between methods and free functions was in
the spirit of a scheme similar to the one above.  I might turn out to be
wrong about the inconsistency, though: I haven't thought this unification
scheme completely through yet.

> > Given this:
> >
> > def f(x):
> >   do_something_width(x)
> >
> > Instead of writing this:
> >
> > class C:
> >   do_f = f
> >
> > Write this:
> >
> > class C:
> >   def do_f():
> >     __module__.f(__instance__) # Where '__module__.' might be optional.
>
> Right -- it doesn't support the existing idiom, so you have to
> code around it with explicit delegation.  Enriching an existing
> class-object from outside the class's body seems even more of
> a problem -- current "C.do_f=f" becomes...?  The "def depends
> on context" defect that you noticed seems to hurt here.

I really don't like to have 'def' depend on context, but in practice it
already does.  In Python as it is, it is possible to turn free functions
into methods but not the other way around.  This is another thing that bears
thinking about, especially in the light of the unification scheme above
(which would break all backwards compatibility anyways).

> > >  Or do you
> > > actually wish to keep things Pythonically simple and is
> > > the C++ reference some sort of red herring?  It's starting
> > > to look that way to me.
> >
> > 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.


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