Deprecate self

[Rainer Deyke]

"Alex Martelli" <aleaxit at yahoo.com> wrote in message
news:9bkvi30uf8 at news1.newsguy.com...
> "Rainer Deyke" <root at rainerdeyke.com> wrote in message
> news:OLlD6.46125$J%5.15304817 at news2.rdc2.tx.home.com...
> How do you stop a class from having subclasses in Python?

def f():
  class C:
    pass
  C()

This is, incidentially, the idiom I had to use extensively to deal with the
lack of nested scoping in Python.  More generally, you write a class for
which subclasses don't make sense.

>  (And
> what is the supposed benefit of that -- assuming you can find any
> benefits for the singleton DP anywhere, of course).

The benefit of enforcing lack of inheritance?  There is none, unless you
believe in the C++/Java way of preventing abuse through access restrictions.
The benefit of singletons?  Consider the following module:

# spam.py
def set_variable(name, value):
  do_something()

def get_variable(name):
  return do_something_else()

def del_variable(name):
  do_something_completely_different()

To facilitate easier access to these functions, I introduce the following
wrapper:

class VariableAccess:
  def __setattr__(self, name, value):
    set_variable(name, value)
  def __getattr__(self, name):
    return get_variable(name)
  def __delattr__(self, name):
    return del_variable(name)
variables = VariableAccess()


Now the client can access the revealed variables through a more natural
interface.

> > >  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
>
> I note you have signally failed to address this horrid defect in the
> analogy you claim "is there".  A method has a global namespace
> _as well_ as access to self as an argument.  If functions were to
> access their global namespace though some magic overloading of
> self, how WOULD methods access THEIR global namespace?

Consider the following hypothetical Python-like language:

def f():
  print 'spam'

class C:
  def f(): # Note lack of 'self'
    print 'eggs'
  def g():
    __instance__.f()
    __module__.f()

I'm not sure I like this myself (the __magic__ names are too long, the
result of a 'def' statement depends on context, there's no clear way to
refer to the outer class from a method in an inner class, magically
appearing variables have the potential to cause trouble, and the
'C.f(instance_of_C)' conventions seems to be broken), but at least it's
better than the strawman against which you seem to have been arguing.

> > 'globals()' is syntactically awkward and semantically different from
> > attribute access.
>
> Yes, for special attributes.  Just as in C++ namespace qualification is
> syntactically and semantically different from attribute access, too, save
> that the Python situation is simpler.

I'm saying specifically that C++ is right in providing a way to qualify
names as global - no more.

> > # Module spam.py
> > import spam
> > print spam.__dict__
> > print globals()['__dict__']
> >
> > A module importing itself is still the best idiom here.
>
> Your choice.  I prefer globals(), myself.

def factorial(n):
  if n <= 1:
    return 1
  else:
    return globals()['factorial'](n - 1)

Do you actually write like that, or do you mean "I am too lazy to explitly
qualify global names, explicit-better-than-implicit be damned, so 'globals'
is good enough for me"?

> > > > namespace jam {
> > > >   int x = 5;
> > > >   void f()
> > > >   {
> > > >     std::cout << ::jam::x << std::endl;
> > > >   }
> > > > }

> A case that will crash and burn as soon as this gets wrapped into
> another namespace (as will no doubt have to happen soon, since
> first thing you know code will have to use this AND another silly
> library using a similarly uninspired namespace name)...? Please.

As a matter of fact, that's another thing Python got wrong.  In the absence
of packages (and Python packages are a hack, an ugly one, and not used by
the standard library anyway), module name collisions are inevitable.  This
is less of a problem in C++ (although probably for the wrong reason):
namespaces with the same fully qualified name can coexist so long as they
don't contain the same name.

In my own code, I don't use demonstrative namespace names like "jam".  But
it doesn't matter anyway.  I can afford to (and do) put all of my names in
the global namespace. :-P

> This use of namespaces is NOT good C++ style.  Sure, you can
> do it -- and get away with it as long as you're playing with toy
> sized systems, maybe.  In real large-scale C++ software, though,
> you had better stick to canonic use.  Please see Meyers' Effective
> C++, CDROM edition, for the most elementary and fundamental
> basics.  Koenig and Moo in "Ruminations on C++" have quite
> usable material, too.  To make a long story short, namespaces
> ARE meant for large-scale software and the top-level namespaces
> had better be unique.  You'll use using-declarations to make such
> long unique namespaces usable.

If I was programming large-scale software, that's exactly what I'd do.

> > 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.
>
> Yet that's what you did -- because (while making no actual usable
> proposals) you started bemoaning the use of self in methods and/or
> its non-use in module-level functions.  These ARE scoping issues,
> after all.  Could you really not be aware of that fact?

The comment I made was quite limited in scope, pun intended.

> > 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.
>
> What would the "over-specialized syntax" you are attacking be
> in this case?  Please be specific.

In this case, the 'global' statement.


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