Deprecate self
Rainer Deyke
root at rainerdeyke.com
Wed Apr 18 19:56:11 EDT 2001
"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
More information about the Python-list
mailing list