Deprecate self

[Rainer Deyke]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:9bkc0t02sac at news1.newsguy.com...
> "Rainer Deyke" <root at rainerdeyke.com> wrote in message
> news:JHhD6.43991$J%5.14895580 at news2.rdc2.tx.home.com...
> > The relationship of a method to the object on which it is called is
> > analogous to the relationship between a free function and its module,
yet
>
> Aha, here's where you see the inconsistency.  The analogy is just
> not there.  A method may be called on objects that are not in its
> class (but rather in a descendant one) while there is nothing of
> the kind about a function -- it's not called "on" a module, much
> less "on" a module somehow different from the one where it gets
> defined.  It's not surprising that you find inconsistency where
> the analogy you thought you saw was never really there.

The analogy is not universally applicable, but it is most certainly "there".
Consider singletons (i.e. classes which by design only have a single
instance and no subclasses).  Or consider random number generators.  The
documentation specifies an interface for random number generators which I
can implement through a module (like module 'random').  If I later decide I
need more than one instance of my random number generator with seperate
state, I can move the functions of that module into a class and use intances
of that class to generate random numbers.  This requires that I add 'self'
as first argument to all functions and 'self.' before all state accesses: a
tedious and error-prone process.

> The module is, basically, just a namespace.

So is a class.  So is a class instance.

class colors:
  red = 0
  green = 1
  blue = 3

class EmptyClass: pass
state = EmptyClass()
state.frame = 0


>  A function, _and_ btw
> a method too, can access that namespace implicitly or explicitly
> [eg via globals()].  It would make no sense for it to be an argument
> to the function since it doesn't change at each call -- while the
> instance on which a method is being called CAN definitely differ
> at each call.
>
> > However, this does not work if 'f' takes a variable number of argument
> (and
> > is tedious besides).  In C++, I can explicitly qualify global variables:
>
> So you can in Python, if you wish -- globals() lets you do that
> most easily.

'globals()' is syntactically awkward and semantically different from
attribute access.

# Module spam.py
import spam
print spam.__dict__
print globals()['__dict__']

A module importing itself is still the best idiom here.


> > namespace jam {
> >   int x = 5;
> >   void f()
> >   {
> >     std::cout << ::jam::x << std::endl;
> >   }
> > }
> >
> > Another thing that C++ got right and Python got wrong.
>
> The intricacies of C++ scoping can hardly be taken as an example
> of things "C++ got right".

I'm not talking about the intricacies of C++ scoping, but this very specific
case.

> Python's scoping is crystal-simple (up to 2.1 excluded -- I have
> not yet delved into the new lexical scoping things deep enough
> to underwrite their simplicity, although one does hope from PEP
> reading & such things:-).

Lack of lexical scoping is another thing Python got wrong.  It causes code
not to work when moved from one scope to another.  However, I had not
intended to start a general discussion of scoping in programming languages.

> In other words, my dislike for C++'s complexities is NOT due
> to insufficient familiarity with them -- indeed, maybe the
> reverse, since I spend so much of my time and energy in
> clarifying the finer points of several combinations of very
> obscure provisions & implementations' bugs to highly skilled
> software development professionals that keep getting badly
> burned by all of the tripwires (I insist that you HAVE to
> mix metaphors A LOT to get into the spirit of C++...:-).

I understand very much the value of simplicity and the horror of C++'s
complexity.  I see inconsitency and over-specialized syntax as the primary
causes, so I attack them in language design whereever I find it - even in
mostly sane languages like Python.


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