Deprecate self

[Alex Martelli]

"Rainer Deyke" <root at rainerdeyke.com> wrote in message
news:JHhD6.43991$J%5.14895580 at news2.rdc2.tx.home.com...
> "Alex Martelli" <aleaxit at yahoo.com> wrote in message
> news:9bjl2901ifj at news1.newsguy.com...
> > "Dave LeBlanc" <whisper at oz.net> wrote in message
> > news:9bji5k$417$0 at 216.39.170.247...
> > > Since self is used for every method of every class, isn't it a bit
> > > redundant?
> >
> > Not really.  Explicit is better than implicit.
>
> The thing that bothers me about using 'self' is that it is inconsistent.

Not really.

> 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 module is, basically, just a namespace.  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.


> 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".  Can you spell "Koenig lookup" and
name two major current C++ implementations that get it wrong?

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:-).  C++'s is one of the most complex
areas in an overly-complex language ('overly' when compared
with human mental capacity, mind you -- I'm not claiming it
could meet its aggressive design goals with simplicity, just
that maybe those design goals were too aggressive).  Please
note that I'm a Brainbench MVP for the C++ language, which,
among other things, means I must be in the upper centile of
scorers in their quiz-like tests -- I'd better, since one of
the main activities that keeps good soup on my table is C++
guruhood/consultancy for my employer (COM is much of the rest,
but, for all of its pragmatical complications, the COM specs
themselves are really much simpler than the ISO C++ Standard;
in COM's case, the complications come on top, in the huge
variety of interfaces and technologies layered on it, geared
to its implementation and support, etc, etc).

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++...:-).

Don't get me wrong -- for all that, C++'s still what I use
by choice to extend or embed Python or implement custom COM
stuff &c.  But, to quote Joy out of context, "Sometimes
when you fill a vacuum it still sucks" (others say it was
Pike, Ritchie, or other such luminaries, who said it first).


Alex