Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Attack a sacred Python Cow

37 views
Skip to first unread message

Jordan

unread,
Jul 24, 2008, 1:41:54 AM7/24/08
to
Hi everyone,

I'm a big Python fan who used to be involved semi regularly in
comp.lang.python (lots of lurking, occasional posting) but kind of
trailed off a bit. I just wrote a frustration inspired rant on my
blog, and I thought it was relevant enough as a wider issue to the
Python community to post here for your discussion and consideration.

This is not flamebait. I love Python, and I'm not out to antagonise
the community. I also realise that one of the issues I raise is way
too ingrained to be changed now. I'd just like to share my thinking on
a misstep in Python's guiding principles that has done more harm than
good IMO. So anyway, here's the post.

I've become utterly convinced that at least one criticism leveled at
my favourite overall programming language, Python, is utterly true and
fair. After quite a while away from writing Python code, I started
last night on a whim to knock up some code for a prototype of an idea
I once had. It's going swimmingly; the Python Image Library, which I'd
never used before, seems quick, intuitive, and with the all the
features I need for this project. As for Python itself, well, my heart
still belongs to whitespace delimitation. All the basics of Python
coding are there in my mind like I never stopped using them, or like
I've been programming in this language for 10 years.

Except when it comes to Classes. I added some classes to code that had
previously just been functions, and you know what I did - or rather,
forgot to do? Put in the 'self'. In front of some of the variable
accesses, but more noticably, at the start of *every single method
argument list.* This cannot be any longer blamed as a hangover from
Java - I've written a ton more code, more recently in Python than in
Java or any other OO language. What's more, every time I go back to
Python after a break of more than about a week or so, I start making
this 'mistake' again. The perennial justification for this 'feature'
of the language? That old Python favourite, "Explicit is better than
implicit."

I'm sorry, but EXPLICIT IS NOT NECESSARILY BETTER THAN IMPLICIT.
Assembler is explicit FFS. Intuitive, clever, dependable, expected,
well-designed *implicit* behaviour is one of the chief reasons why I
use a high level language. Implicitly garbage collect old objects for
me? Yes, please!

I was once bitten by a Python wart I felt was bad enough to raise and
spend some effort advocating change for on comp.lang.python (never got
around to doing a PEP; partly laziness, partly young and inexperienced
enough to be intimidated at the thought. Still am, perhaps.)

The following doesn't work as any sane, reasonable person would
expect:

# Blog code, not tested
class A():
def __eq__(self, obj):
return True
a = A()
b = []
assert a == b
assert not (a != b)

The second assertion fails. Why? Because coding __eq__, the most
obvious way to make a class have equality based comparisons, buys you
nothing from the != operator. != isn't (by default) a synonym for the
negation of == (unlike in, say, every other language ever); not only
will Python let you make them mean different things, without
documenting this fact - it actively encourages you to do so.

There were a disturbingly high number of people defending this
(including one quite renowned Pythonista, think it might have been
Effbot). Some had the temerity to fall back on "Explicit is better
than implict: if you want != to work, you should damn well code
__ne__!"

Why, for heaven's sake, should I have to, when in 99.99% of use cases
(and of those 0.01% instances quoted in the argument at the time only
one struck me as remotely compelling) every programmer is going to
want __ne__ to be the logical negation of __eq__? Why, dear Python,
are you making me write evil Java-style language power reducing
boilerplate to do the thing you should be doing yourself anyway?
What's more, every programmer is going to unconciously expect it to
work this way, and be as utterly as mystified as me when it fails to
do so. Don't tell me to RTFM and don't tell me to be explicit. I'll
repeat myself - if I wanted to be explicit, I'd be using C and
managing my own memory thank you very much. Better yet, I'd explicitly
and graphically swear - swear in frustration at this entrenched design
philosophy madness that afflicts my favourite language.

I think the real problem with the explicit is better than implicit,
though, is that while you can see the underlying truth its trying to
get at (which is perhaps better expressed by Ruby's more equivocal,
less dependable, but more useful Principle of Least Surprise), in its
stated form its actually kind of meanginless and is used mainly in
defence of warts - no, we'll call them for what they are, a language
design *bugs*.

You see, the problem is, there's no such thing of explict in
programming. Its not a question of not doing things implicitly; its a
question of doing the most sensible thing implicitly. For example this
python code:

some_obj.some_meth(some_arg1, some_arg2)

is implicitly equivalent to

SomeClass.some_meth(some_obj, some_arg1, some_arg2)

which in turn gives us self as a reference to some_obj, and Python's
OO model merrily pretends its the same as Java's when in fact is a
smarter version that just superficially looks the same.

The problem is that the explicit requirement to have self at the start
of every method is something that should be shipped off to the
implicit category. You should have to be explicit, yes - explicit when
you want the *other* behaviour, of self *not* being an argument,
because thats the more unusual, less likely case.

Likewise,

a != b

is implicitly equivalent to something like calling this function (may
not be correct, its a while since I was heavily involved in this
issue):

def equal(a, b):
if hasattr(a, "__ne__"): return a.__ne__(b)
if hasattr(b, "__ne__"): return b.__ne__(a)
if hasattr(a, "__cmp__"): return not (a.__cmp__(b) == 0)
if hasattr(b, "__cmp__"): return not (b.__cmp__(a) == 0)
return not (a is b)

There's absolutely nothing explicit about this. I wasn't arguing for
making behaviour implicit; I was arguing for changing the stupid
implict behaviour to something more sensible and less surprising.

The sad thing is there are plenty of smart Python programmers who will
justify all kinds of idiocy in the name of their holy crusade against
the implict.

If there was one change I could make to Python, it would be to get
that damn line out of the Zen.

Jordan

unread,
Jul 24, 2008, 1:46:38 AM7/24/08
to

P.S. Forgive the typos, it was blogged in extreme haste and then only
quickly proofread and edited before posting here. Hopefully the point
I'm making is not diminshed by your reduced respect for me as a result
of my carelessness :-)

pluskid

unread,
Jul 24, 2008, 2:39:13 AM7/24/08
to
On Jul 24, 1:41 pm, Jordan <jordanrastr...@gmail.com> wrote:
> Hi everyone,
>
> I'm a big Python fan who used to be involved semi regularly in
> comp.lang.python (lots of lurking, occasional posting) but kind of
> trailed off a bit. I just wrote a frustration inspired rant on my
> blog, and I thought it was relevant enough as a wider issue to the
> Python community to post here for your discussion and consideration.
>
[...snip...]

+1 for most of your opinion. I was also bitten by the __eq__/__ne__
problem this morning. :)

Fredrik Lundh

unread,
Jul 24, 2008, 3:48:03 AM7/24/08
to pytho...@python.org
Jordan wrote:

> Except when it comes to Classes. I added some classes to code that had
> previously just been functions, and you know what I did - or rather,
> forgot to do? Put in the 'self'. In front of some of the variable
> accesses, but more noticably, at the start of *every single method
> argument list.* This cannot be any longer blamed as a hangover from
> Java - I've written a ton more code, more recently in Python than in
> Java or any other OO language. What's more, every time I go back to
> Python after a break of more than about a week or so, I start making
> this 'mistake' again. The perennial justification for this 'feature'
> of the language? That old Python favourite, "Explicit is better than
> implicit."

Do you seriously think that Python is designed by mindless application
of a set of humorous and somewhat self-deprecating observations posted
to a newsgroup a number of years ago?

</F>

Jordan

unread,
Jul 24, 2008, 4:11:47 AM7/24/08
to
Of course not.

I just think Explicit is better than Implicit is taken seriously by a
large segment the Python community as a guiding principle, and overall
its influence does more harm than good.

Clearly self being in every argument list was a decision arrived at
long before the Zen was ever coined. Its merely an example of what I
feel is a shortcoming in the conventional 'pythonic' approach to
thinking about problems.

The reluctance to admit that the __eq__ behaviour is a poor design
choice is further evidence; its something (unlike self) that quite
conceivably could be changed, and should be changed, but its somehow
seen (by certain people) as the way that Python should do things.

Bruno Desthuilliers

unread,
Jul 24, 2008, 5:26:40 AM7/24/08
to
Jordan a écrit :

(snip rant about self and __eq__ / __ne__)

1/ about the __eq__ / __ne__ stuff:

Please get your facts, the behaviour *is* actually fully documented:

"""
There are no implied relationships among the comparison operators. The
truth of x==y does not imply that x!=y is false. Accordingly, when
defining __eq__(), one should also define __ne__() so that the operators
will behave as expected.
"""
http://docs.python.org/ref/customization.html

FWIW, the __lt__ / __le__ / __eq__ / __ne__ / __gt__ / __ge__ methods
set, known as "rich comparisons", was added in Python 2.1 to give more
fine-grained control on comparisons. If you don't need such a
granularity, just implement the __cmp__ method and you'll have all
comparison operators working as expected.

2/ wrt/ self in functions signatures:

How would you handle this case with an implicit 'self' :

class Foo(object):
pass

def bar(self):
print self

Foo.bar = bar

Torsten Bronger

unread,
Jul 24, 2008, 5:40:46 AM7/24/08
to
Hallöchen!

Bruno Desthuilliers writes:

> [...]


>
> How would you handle this case with an implicit 'self' :
>
> class Foo(object):
> pass
>
> def bar(self):
> print self
>
> Foo.bar = bar

Just like this. However, the compiler could add "self" to
non-decorated methods which are defined within "class".

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: torsten...@jabber.rwth-aachen.de

Jordan

unread,
Jul 24, 2008, 5:58:26 AM7/24/08
to
On Jul 24, 7:40 pm, Torsten Bronger <bron...@physik.rwth-aachen.de>
wrote:
>                    Jabber ID: torsten.bron...@jabber.rwth-aachen.de

Yeah, forgot what I said, Torsten's reply is much better :-)

Lawrence D'Oliveiro

unread,
Jul 24, 2008, 6:01:23 AM7/24/08
to
In message
<52404933-ce08-4dc1...@r35g2000prm.googlegroups.com>, Jordan
wrote:

> Except when it comes to Classes. I added some classes to code that had
> previously just been functions, and you know what I did - or rather,
> forgot to do? Put in the 'self'. In front of some of the variable
> accesses, but more noticably, at the start of *every single method
> argument list.*

The reason is quite simple. Python is not truly an "object-oriented"
language. It's sufficiently close to fool those accustomed to OO ways of
doing things, but it doesn't force you to do things that way. You still
have the choice. An implicit "self" would take away that choice.

Sebastian "lunar" Wiesner

unread,
Jul 24, 2008, 6:02:15 AM7/24/08
to
Jordan <jordanr...@gmail.com>:


> # Blog code, not tested
> class A():
> def __eq__(self, obj):
> return True
> a = A()
> b = []
> assert a == b
> assert not (a != b)
>
> The second assertion fails. Why? Because coding __eq__, the most
> obvious way to make a class have equality based comparisons, buys you
> nothing from the != operator. != isn't (by default) a synonym for the
> negation of == (unlike in, say, every other language ever);

This is just plain wrong for at least C# and C++. C# wants you to
explicitly overload "!=", if you have overloaded "==", C++ complains
about "!=" not being defined for class A. If you had derived A from a
another class in C++, the compiler would happily use the operator from the
base class instead of doing silly aliasing of "!=" to "! ==" ...

> The sad thing is there are plenty of smart Python programmers who will
> justify all kinds of idiocy in the name of their holy crusade against
> the implict.
>
> If there was one change I could make to Python, it would be to get
> that damn line out of the Zen.

Fortunately, Python isn't designed according to your ideas, and won't
change, so consider your posting a waste of time. If feeling like bringing
such old "issues" up again next time, spend your time learning another
programming language, as you would obviously not get happy with Python
anyway ...

--
Freedom is always the freedom of dissenters.
(Rosa Luxemburg)

Jordan

unread,
Jul 24, 2008, 6:12:41 AM7/24/08
to
OK, it seems my original reply to Bruno got lost in the Aether
(apologies therefore if a paraphrased "quantum duplicate" of this
message is eventually forthcoming.)

Torsten has adequately responded to his second point, so I need only
replicated what I said for the first.

> Please get your facts, the behaviour *is* actually fully documented:

I have the facts. I know full well the behaviour is documented - it
was pointed out at the time of the original discussion. Documenting a
confusing, unintuitive design decision (whether its in a programming
language, an end user GUI app or anything in between) doesn't justify
it.

To attack a strawman: "foolanguage uses the bar IO library; printing
to stdout takes about 10 mins on the average machine. But thats ok,
because look, its documented right here."

> FWIW, the __lt__ / __le__ / __eq__ / __ne__ / __gt__ / __ge__ methods
> set, known as "rich comparisons", was added in Python 2.1 to give more
> fine-grained control on comparisons. If you don't need such a
> granularity, just implement the __cmp__ method and you'll have all
> comparison operators working as expected.

First, the most serious justification for rich comparisons I remember
seeing was that scipy "needed" them. I never saw a good reason scipy
couldnt use methods like the rest of us mortals, nor why it was
justifiable introducing a wart into the entire language for the sake
of mildly conveniencing an (admittedly important and widely used)
library.

Second, fine, have silly C++-operator-overloading-style rich
comparisons that confuse people reading your code if you must. Why
does it have to be the default behaviour? Its people wanting __ne__ do
do something other than not __eq__ who should have to be explicit
about it.

Third, __cmp__ is no good as a fix. Most classes that wan't equality
comparison (== and !=) don't want ordered based comparison (>= etc.)
thrown in as well. I shouldn't implement __cmp__ unless I want my
class to implement every order comparison operator.

Fourth, I'm trying to examine the wider implications of the Explicit >
Implict mantra here, not resurrect an old campaign to change !=
behaviour that I think is probably a lost cause (if it happens as a
side effect though, that'd be kinda cool.)

Jordan

unread,
Jul 24, 2008, 6:21:20 AM7/24/08
to

> This is just plain wrong for at least C# and C++.  C# wants you to
> explicitly overload "!=", if you have overloaded "==",

While this is as inconvenient as Python at least it doesn't catch you
unawares. C# 1 (or maybe 0.5), Python 0.

> C++ complains
> about "!=" not being defined for class A.  

See above. C++ 1, Python 0.

So in showing my clearly hyperbolic comment was technically incorrect
(something I could have told you myself), you have merely shown that
two languages I find vastly inferior to Python overall are actually
better than it in this case.

> Fortunately, Python isn't designed according to your ideas, and won't
> change, so consider your posting a waste of time.  If feeling like bringing
> such old "issues" up again next time, spend your time learning another
> programming language, as you would obviously not get happy with Python
> anyway ...

OK, if that's your response, that's sad. Of course, I try to learn new
languages all the time. Python is still IMO the best. If the attitude
in the community in response to feedback/criticism has gone from
"maybe you've got a point" to "your a lunatic, we'll never change",
well, only Python will suffer in the long term.

Jordan

unread,
Jul 24, 2008, 6:24:31 AM7/24/08
to
On Jul 24, 8:01 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> In message
> <52404933-ce08-4dc1-a558-935bbbae7...@r35g2000prm.googlegroups.com>, Jordan

You could still explicitly request non-implicit self on a method by
method basis.

Kay Schluehr

unread,
Jul 24, 2008, 6:40:59 AM7/24/08
to
On 24 Jul., 11:40, Torsten Bronger <bron...@physik.rwth-aachen.de>
wrote:

> Hallöchen!
>
> Bruno Desthuilliers writes:
> > [...]
>
> > How would you handle this case with an implicit 'self' :
>
> > class Foo(object):
> > pass
>
> > def bar(self):
> > print self
>
> > Foo.bar = bar
>
> Just like this. However, the compiler could add "self" to
> non-decorated methods which are defined within "class".

And $self2, $self3, ... to the object methods of nested classes and
$cls2, $cls3, ... to the classmethods of those classes...?

And when we are at it, here is a nice little exercise for the
proponents of compiler magic.

Write a decorator that takes and returns a method and prints the
object the method is bound to. It's very easy to do it when the object
is passed explicitely:

def print_self(func):
def call(self, *args, **kwd):
print self
return func(self, *args, **kwd)
return call

Conceptual clarity isn't always an entirely bad thing to have.

Torsten Bronger

unread,
Jul 24, 2008, 6:47:36 AM7/24/08
to
Hallöchen!

Kay Schluehr writes:

> On 24 Jul., 11:40, Torsten Bronger <bron...@physik.rwth-aachen.de>
> wrote:
>>
>> Bruno Desthuilliers writes:
>>
>>> [...]
>>>
>>> How would you handle this case with an implicit 'self' :
>>>
>>> class Foo(object):
>>> pass
>>>
>>> def bar(self):
>>> print self
>>>
>>> Foo.bar = bar
>>
>> Just like this. However, the compiler could add "self" to
>> non-decorated methods which are defined within "class".
>
> And $self2, $self3, ... to the object methods of nested classes
> and $cls2, $cls3, ... to the classmethods of those classes...?

One could surely find ways to realise this. However, the design
goal should be: Make the frequent case simple, and the rare case
possible.

(Actually, I'm -0 on this anyway because I forget "self" very
seldomly, and you would still have ".self" all over the place.)

alex23

unread,
Jul 24, 2008, 8:40:16 AM7/24/08
to
On Jul 24, 8:21 pm, Jordan <jordanrastr...@gmail.com> wrote:
> If the attitude
> in the community in response to feedback/criticism has gone from
> "maybe you've got a point" to "your a lunatic, we'll never change",
> well, only Python will suffer in the long term.

Personally, I think it has more to do with statements like "there are


plenty of smart Python programmers who will

justify all kinds of idiocy in the name of their holy crusade" than
with your position. You don't begin a discussion by discrediting
anyone who might disagree with you as some kind of religious bigot
while simultaneously holding that you are the only sane voice
speaking.

Sebastian "lunar" Wiesner

unread,
Jul 24, 2008, 9:11:49 AM7/24/08
to
Jordan <jordanr...@gmail.com>:

>> Fortunately, Python isn't designed according to your ideas, and won't
>> change, so consider your posting a waste of time.  If feeling like
>> bringing such old "issues" up again next time, spend your time learning
>> another programming language, as you would obviously not get happy with
>> Python anyway ...
>
> OK, if that's your response, that's sad. Of course, I try to learn new
> languages all the time. Python is still IMO the best. If the attitude
> in the community in response to feedback/criticism has gone from
> "maybe you've got a point" to "your a lunatic, we'll never change",
> well, only Python will suffer in the long term.

I don't really mind, what you think about my response. Python will suffer
from it as little as it will suffer from your complaints: These things
will not change, whatever any of us says about them. So this discussion
unlikely to produce any new insight, especially because this as been
discussed over and over again in the past, without any effect on Python.

Let's just drop this, and if you want to complain next time, just complain
about something, that is really worth being complained about, like for
instance old and outdated modules in the standard library, or real
showstoppers in Python (e.g. the GIL).

Jordan

unread,
Jul 24, 2008, 10:07:02 AM7/24/08
to
> Personally, I think it has more to do with statements like "there are
> plenty of smart Python programmers who will
> justify all kinds of idiocy in the name of their holy crusade" than
> with your position. You don't begin a discussion by discrediting
> anyone who might disagree with you as some kind of religious bigot
> while simultaneously holding that you are the only sane voice
> speaking.

I didn't set out to discredit anyone who might disagree with me; in
fact I didn't in anyway try to pre-empt any person who might disagree
with my thesis. I merely stated an observation - I have in the past
seen seemingly intelligent people take silly stands in the name of
Explicit is greater than Implicit (not just on comp.lang.python, and
not just concerning != or self).

I wish in retrospect I'd had the time, patience and focus to edit the
initial post to make it more measured and less inflammatory, because
its clear the tone detracts from the argument I'm making, which I feel
still stands.

So if you wish, ignore the specifics of the frustration that inspired
me and consider only the thrust of what I'm saying:

"Explicit is better than Implict" considered harmful. Discuss.

Ben Finney

unread,
Jul 24, 2008, 10:08:15 AM7/24/08
to
Jordan <jordanr...@gmail.com> writes:

> I just think Explicit is better than Implicit is taken seriously by
> a large segment the Python community as a guiding principle

Indeed it is. However, it has to compete with all the other principles
in the Zen of Python, which have equal status.

> and overall its influence does more harm than good.

Thanks for your opinion. I disagree strongly: I think its influence is
nicely balanced by the other important principles that are also
followed.

--
\ “The way to build large Python applications is to componentize |
`\ and loosely-couple the hell out of everything.” —Aahz |
_o__) |
Ben Finney

Ben Finney

unread,
Jul 24, 2008, 10:12:05 AM7/24/08
to
Jordan <jordanr...@gmail.com> writes:

> If the attitude in the community in response to feedback/criticism
> has gone from "maybe you've got a point" to "your a lunatic, we'll
> never change", well, only Python will suffer in the long term.

You're not a lunatic.

We, and Python itself, change quite readily.

Neither of those mean your ideas in this instance have merit.

--
\ “Pinky, are you pondering what I'm pondering?” “Well, I think |
`\ so, Brain, but do I really need two tongues?” —_Pinky and The |
_o__) Brain_ |
Ben Finney

Jordan

unread,
Jul 24, 2008, 10:26:03 AM7/24/08
to
> I don't really mind, what you think about my response.  Python will suffer
> from it as little as it will suffer from your complaints:  These things
> will not change, whatever any of us says about them.  So this discussion
> unlikely to produce any new insight, especially because this as been
> discussed over and over again in the past, without any effect on Python.  

You're right, of course. Because Python is in so many ways what I'm
looking for in a language, I transform it in my mind to my own,
personal ideal, close to the real existing language but with what I
consider to be the imperfections removed.

I'm not suggesting getting rid of explicit self, even in "Python
4000." Not because of the advantages it gives, which are some but
don't outweigh the net loss in my ledger. It just wouldn't be
Pythonic. I know its not a Pythonic thing to want. Thats my problem -
because I have a largely Pythonic approach in some areas, it upsets me
when there's a mismatch. So lets say I'm -1 for introducing it into a
language and +0 for keeping it in Python now that its entrenched.

If a lot of users keep bringing up something like this, well my
attitude used to be the same as yours - "learn to love Python for what
it is." Maybe

> Let's just drop this, and if you want to complain next time, just complain
> about something, that is really worth being complained about, like for
> instance old and outdated modules in the standard library, or real
> showstoppers in Python (e.g. the GIL).

Its worth complaining about because I'm not just someone who has
stumbled across Python after years of Java and PHP, and hasn't really
grokked it, and has jumped on the net at once to start a flamewar. I'm
someone who loves Python, uses it in preference to other languages,
and have now returned to it after a bit of a break and its finally hit
me over the head like a tonne of bricks "Hey, I can see exactly what
all those internet trolls were talking about. This *is* a really
annoying and silly state of affairs."

I was trying not to change explicit self, or even != (which has a much
better case.) I was trying to ask the community to reconsider a
premise that the language is built around. Explicit is actually kinda
annoying a lot of the time, viz., java. This is about social and
philosophical adjustments, not technical ones.

In reality? I'll just keep writing Python (hopefully enough so that
explicit self become burned into muscle memory), and use other
languages when necessary (no more C than I have to, looking forward to
dabbling in Erlang soon, and one day overcoming the parentheses phobia
enough to really tackle Lisp properly). When I'm old enough and wise
enough, and have the time, energy and inclination, maybe I'll sit down
and put a proper effort into designing and implementing a new language
that bests suits my own particular style and needs. Just maybe it'll
be good enough that smart people will rally to defend its design
principles from people attacking them on the internet :-)

Bruno Desthuilliers

unread,
Jul 24, 2008, 8:51:20 AM7/24/08
to
Jordan a écrit :

> OK, it seems my original reply to Bruno got lost in the Aether
> (apologies therefore if a paraphrased "quantum duplicate" of this
> message is eventually forthcoming.)
>
> Torsten has adequately responded to his second point,

Not MHO, by far.

> so I need only
> replicated what I said for the first.
>
>> Please get your facts, the behaviour *is* actually fully documented:
>
> I have the facts. I know full well the behaviour is documented

Then why do you write, let me quote:

"""
(snip) coding __eq__ (snip) buys you


nothing from the != operator. != isn't (by default) a synonym for the
negation of == (unlike in, say, every other language ever); not only
will Python let you make them mean different things, without
documenting this fact - it actively encourages you to do so.
"""

>- it
> was pointed out at the time of the original discussion. Documenting a
> confusing, unintuitive design decision (whether its in a programming
> language, an end user GUI app or anything in between) doesn't justify
> it.

I was not commenting on the actual design choice, just stating that it
is actually documented.

> To attack a strawman: "foolanguage uses the bar IO library; printing
> to stdout takes about 10 mins on the average machine. But thats ok,
> because look, its documented right here."

And you're talking about strawman ??? Come on, you obviously can tell
the difference between a one-line statement and your above strawman
argument, don't you ?

Please understand that I'm not arguing about this particular design
choice (and FWIW, I'd mostly agree on the point that having a != b
different from not (a == b) is actually a wart). I'm just correcting
your statement about the behaviour of __eq__ / __ne__ not being
documented, which is obviously false.

(snip)

Bruno Desthuilliers

unread,
Jul 24, 2008, 8:59:26 AM7/24/08
to
Torsten Bronger a écrit :

> Hallöchen!
>
> Bruno Desthuilliers writes:
>
>> [...]
>>
>> How would you handle this case with an implicit 'self' :
>>
>> class Foo(object):
>> pass
>>
>> def bar(self):
>> print self
>>
>> Foo.bar = bar
>
> Just like this. However, the compiler could add "self" to
> non-decorated methods which are defined within "class".

What's defined within classes are plain functions. It's actually the
lookup mechanism that wraps them into methods (and manage to insert the
current instance as first argument).

cokof...@gmail.com

unread,
Jul 24, 2008, 11:00:19 AM7/24/08
to
>
> Please understand that I'm not arguing about this particular design
> choice (and FWIW, I'd mostly agree on the point that having a != b
> different from not (a == b) is actually a wart). I'm just correcting
> your statement about the behaviour of __eq__ / __ne__ not being
> documented, which is obviously false.
>
> (snip)

What was the reasoning behind having both __eq__ / __ne__ anyway? To
fit in with the equality comparisons? I do agree this one seems like
a wart, but not a serious one. I'd say it would make more sense for
the interpreter to provide a warning on classes that define one and
not that other, at least if set to a certain level, similar to -3 for
depreciated.

(Or does this exist? I think a "wart" catching level that outputs
potential warts and issues would be a useful addition!)

Jordan

unread,
Jul 24, 2008, 11:03:45 AM7/24/08
to
> Then why do you write, let me quote:
>
> """
> (snip) coding __eq__ (snip) buys you
> nothing from the != operator. != isn't (by default) a synonym for the
> negation of == (unlike in, say, every other language ever); not only
> will Python let you make them mean different things, without
> documenting this fact - it actively encourages you to do so.
> """

My words aren't as clear as they should be. I mean that Python lets
*you* do something without documenting, or rather stating to use a
better term, that your intention is the non-obvious one. I'm not
saying that Python itself lacks documentation for its own behaviour;
I'm saying it should force you to make your intentions clear and
visible to someone reading your code when you want to do something non-
obvious.

> I was not commenting on the actual design choice, just stating that it
> is actually documented.

Yes, it is. I apologise for the poor construction of my statement
which led to this confusion.

> And you're talking about strawman ??? Come on, you obviously can tell
> the difference between a one-line statement and your above strawman
> argument, don't you ?

I'm talking about strawmen because I was deliberately choosing to
invoke one with rhetorical flourish for the purposes of making my
point forcefully. I wanted people to be clear that I knew perfectly
well what I was doing and that they needn't call me out on it.

> Please understand that I'm not arguing about this particular design
> choice (and FWIW, I'd mostly agree on the point that having a != b
> different from not (a == b) is actually a wart). I'm just correcting
> your statement about the behaviour of __eq__ / __ne__ not being
> documented, which is obviously false.

Good, at least we've come to a point in this discussion where I can
firmly agree with somebody.

Bruno Desthuilliers

unread,
Jul 24, 2008, 9:07:07 AM7/24/08
to
Torsten Bronger a écrit :

> Hallöchen!
>
> Kay Schluehr writes:
>
>> On 24 Jul., 11:40, Torsten Bronger <bron...@physik.rwth-aachen.de>
>> wrote:
>>> Bruno Desthuilliers writes:
>>>
>>>> [...]
>>>>
>>>> How would you handle this case with an implicit 'self' :
>>>>
>>>> class Foo(object):
>>>> pass
>>>>
>>>> def bar(self):
>>>> print self
>>>>
>>>> Foo.bar = bar
>>> Just like this. However, the compiler could add "self" to
>>> non-decorated methods which are defined within "class".
>> And $self2, $self3, ... to the object methods of nested classes
>> and $cls2, $cls3, ... to the classmethods of those classes...?
>
> One could surely find ways to realise this. However, the design
> goal should be: Make the frequent case simple, and the rare case
> possible.

Given the (more and more prominent) use of decorators, metaclasses and
other meta-programming techniques in Python, I'm not sure the cases
where you really need access to Python's object model inners are that
"rare". Not in my code at least.

cokof...@gmail.com

unread,
Jul 24, 2008, 11:07:34 AM7/24/08
to
>
> My words aren't as clear as they should be. I mean that Python lets
> *you* do something without documenting, or rather stating to use a
> better term, that your intention is the non-obvious one. I'm not
> saying that Python itself lacks documentation for its own behaviour;
> I'm saying it should force you to make your intentions clear and
> visible to someone reading your code when you want to do something non-
> obvious.
>

I take it you are relating to the need for less comments within the
code as the idea is the Python code itself is readable? Or are you
saying that when someone does a clever trick it should be documented
better? I'm a little confused as what you mean by no-documenting? I
always add doc-strings to modules I will be using heavily as well as a
README with them. But that isn't different from programming in other
languages and using comments.

(Do you mean something like JavaDoc?)

Ben Finney

unread,
Jul 24, 2008, 11:09:54 AM7/24/08
to
Jordan <jordanr...@gmail.com> writes:

> Explicit is actually kinda annoying a lot of the time

Yes. It is also very helpful for those who will later try to
understand, interface with, debug, modify, or otherwise work with the
code (including, in a great many cases, the original author of that
code).

The great boost that EIBTI grants to maintainability trumps, in my
view, the annoyance felt by some at the time of writing the code.

--
\ “An eye for an eye would make the whole world blind.” —Mahatma |
`\ Gandhi |
_o__) |
Ben Finney

Bruno Desthuilliers

unread,
Jul 24, 2008, 9:16:31 AM7/24/08
to
Lawrence D'Oliveiro a écrit :

> In message
> <52404933-ce08-4dc1...@r35g2000prm.googlegroups.com>, Jordan
> wrote:
>
>> Except when it comes to Classes. I added some classes to code that had
>> previously just been functions, and you know what I did - or rather,
>> forgot to do? Put in the 'self'. In front of some of the variable
>> accesses, but more noticably, at the start of *every single method
>> argument list.*
>
> The reason is quite simple. Python is not truly an "object-oriented"
> language.

Oh yes ? What's missing exactly ? You have objects that have an id,
state and behaviour, and you have a message-passing mechanism.

You meant "Python is not truly a mainstream class-based language", I think.

> It's sufficiently close to fool those accustomed to OO ways of
> doing things,

s/OO/class-based/

> but it doesn't force you to do things that way. You still
> have the choice. An implicit "self" would take away that choice.

It's not even a question of OO/non-OO. An implicit "self" would take
away some things that makes Python's *object* model so powerful.

Jordan

unread,
Jul 24, 2008, 11:17:36 AM7/24/08
to
>
> You're not a lunatic.
>
> We, and Python itself, change quite readily.
>
> Neither of those mean your ideas in this instance have merit.

You're right, these premises don't lead to this conclusion. Neither do
they lead to its negation, of course.

As it happens, you're wrong on both counts. I do in fact suffer from a
mental illness and have spent a week in a psych ward, so am a lunatic
by some reasonable definitions. Python readily changes in some
regards, but not in others. Of course, a great many things of worth
have this as one of their essential qualities.

Pithy replies are fun.

> Thanks for your opinion. I disagree strongly: I think its influence is
> nicely balanced by the other important principles that are also
> followed.

This isn't just being clever, there's substance here. A clearly stated
opposing position, with a decent if somewhat short justification.

I think you're right insofar as you go - that if someone really sits
down, and thinks clearly about all the Pythonic principles, as a
whole, and in detail, then the net result in the shaping their
thinking will be positive more often than not.

Perhaps we're just looking at an instance of a wider problem - smart
people boil good ideas down into short slogans, which are nice and
memorable and somewhat helpful, but can lead to bad consequences when
lots of others start overusing or misunderstanding them.

Tim Golden

unread,
Jul 24, 2008, 11:25:37 AM7/24/08
to pytho...@python.org
Just wondered whether the OP's Subject was a
deliberate play on "flog a dead horse" or
merely an ironic one :)

TJG

Torsten Bronger

unread,
Jul 24, 2008, 11:36:45 AM7/24/08
to
Hallöchen!

Bruno Desthuilliers writes:

> Torsten Bronger a écrit :


>
>> Kay Schluehr writes:
>>
>>> On 24 Jul., 11:40, Torsten Bronger <bron...@physik.rwth-aachen.de>
>>> wrote:
>>>

>>>> [...] Just like this. However, the compiler could add "self"


>>>> to non-decorated methods which are defined within "class".
>>>
>>> And $self2, $self3, ... to the object methods of nested classes
>>> and $cls2, $cls3, ... to the classmethods of those classes...?
>>
>> One could surely find ways to realise this. However, the design
>> goal should be: Make the frequent case simple, and the rare case
>> possible.
>
> Given the (more and more prominent) use of decorators, metaclasses
> and other meta-programming techniques in Python, I'm not sure the
> cases where you really need access to Python's object model inners
> are that "rare". Not in my code at least.

What does "not rare" mean for you?

Torsten Bronger

unread,
Jul 24, 2008, 11:39:28 AM7/24/08
to
Hallöchen!

Bruno Desthuilliers writes:

> Torsten Bronger a écrit :
>

And why does this make the implicit insertion of "self" difficult?
I could easily write a preprocessor which does it after all.

Paul Boddie

unread,
Jul 24, 2008, 11:46:29 AM7/24/08
to
On 24 Jul, 12:02, "Sebastian \"lunar\" Wiesner"

<basti.wies...@gmx.net> wrote:
>
> Fortunately, Python isn't designed according to your ideas, and won't
> change, so consider your posting a waste of time.

This is the kind of petty response that serves only to shut down
discussion that might actually lead to genuine attempts to remedy
issues (or "warts") with Python. Although the tone of the complaint
was badly chosen, it is always worth jumping over the fence and
considering whether things could be made better. Without complaints
being aired, how do you expect any advances around things like the


"old and outdated modules in the standard library, or real

showstoppers in Python (e.g. the GIL)" that you mention elsewhere?

> If feeling like bringing such old "issues" up again next time, spend
> your time learning another programming language, as you would
> obviously not get happy with Python anyway ...

Such a constructive response that is! Instead, I think it is
interesting to consider why methods still require an explicit "self"
parameter - something which has been discussed previously - and
whether there might be a case for omitting it from the signature -
perhaps in a variant of Python - in methods which are defined within
class definitions (as opposed to those assigned to classes later).

Indeed, there's scope for experimentation with Python variants, just
to investigate whether certain features added to CPython can be
considered essential, and which features might be considered of
marginal benefit. I recall that some features (eg. lexical scoping and
closures) were eventually added to Python partly to remedy issues with
lambda definitions, but also because the lack of such features was
cited repeatedly by proponents of other languages. In such a climate,
it can be easier to "meet the challenge" and implement features to
silence the critics rather than to insist that they are of marginal
benefit (although it's interesting to note this in a thread where
improvement suggestions are deemed "a waste of time" - I suppose the
community is now more resistant to suggestions from "unofficial"
sources).

A review of such language "enhancement" decisions would be
interesting, but since one shouldn't expect this from the CPython
implementers, I feel that it is the role of others to do so in their
own experiments. Of course, such experiments are often derided as
"lesser Pythons" or misunderstood, but that's another unfortunate
trait exhibited by parts of the Python community.

Paul

Sebastian "lunar" Wiesner

unread,
Jul 24, 2008, 12:49:16 PM7/24/08
to
Torsten Bronger <bro...@physik.rwth-aachen.de>:

> Hallöchen!
>
> Bruno Desthuilliers writes:
>
>> Torsten Bronger a écrit :
>>
>>> Bruno Desthuilliers writes:
>>>
>>>> [...]
>>>>
>>>> How would you handle this case with an implicit 'self' :
>>>>
>>>> class Foo(object):
>>>> pass
>>>>
>>>> def bar(self):
>>>> print self
>>>>
>>>> Foo.bar = bar
>>>
>>> Just like this. However, the compiler could add "self" to
>>> non-decorated methods which are defined within "class".
>>
>> What's defined within classes are plain functions. It's actually
>> the lookup mechanism that wraps them into methods (and manage to
>> insert the current instance as first argument).
>
> And why does this make the implicit insertion of "self" difficult?
> I could easily write a preprocessor which does it after all.

Who said, that it would be "difficult"? He just corrected your statement
about definitions inside a class, and did not make any assumption about
making "self" implicit.

I'd assume, that making self implicit wouldn't be that difficult to assume.
But does the fact, that it could easily be done, alone mean, that it
_should_ be done? The explicit "self" was a design decision, that can't
really be judged by technical arguments from implementation side. Its a
discussion about design from a programmers point of view ...

alex23

unread,
Jul 24, 2008, 1:03:35 PM7/24/08
to
On Jul 25, 1:39 am, Torsten Bronger <bron...@physik.rwth-aachen.de>
wrote:

> I could easily write a preprocessor which does it after all.

Have you considered actually doing so? That might resolve the whole
issue, if a tool exists for those who want implicit self. After all,
if -you- have the itch...

Perhaps you could leverage off of EasyExtend?

"EasyExtend (EE) is a preprocessor generator and metaprogramming
framework written in pure Python and integrated with CPython. The main
purpose of EasyExtend is the creation of extension languages i.e.
adding custom syntax and semantics to Python."

http://www.fiber-space.de/EasyExtend/doc/EE.html

Bruno Desthuilliers

unread,
Jul 24, 2008, 11:04:50 AM7/24/08
to
Torsten Bronger a écrit :

> Hallöchen!
>
> Bruno Desthuilliers writes:
>
>> Torsten Bronger a écrit :
>>
>>> Bruno Desthuilliers writes:
>>>
>>>> [...]
>>>>
>>>> How would you handle this case with an implicit 'self' :
>>>>
>>>> class Foo(object):
>>>> pass
>>>>
>>>> def bar(self):
>>>> print self
>>>>
>>>> Foo.bar = bar
>>> Just like this. However, the compiler could add "self" to
>>> non-decorated methods which are defined within "class".
>> What's defined within classes are plain functions. It's actually
>> the lookup mechanism that wraps them into methods (and manage to
>> insert the current instance as first argument).
>
> And why does this make the implicit insertion of "self" difficult?

Did I say such a thing ?

Call me pedantic if you want, but I find it easier to understand how
something works when using the appropriate terms, that's all.

> I could easily write a preprocessor which does it after all.

A source-code-preprocessor based solution wouldn't do IMHO. But that was
not the point. The point is that a working solution would require to
handle "functions-or-else" defined within a class statement as a special
case, which obviously makes thing more compl[ex|icated]. Now as far as
I'm concerned, as long as such a solution 1/ doesn't impose any
restriction wrt/ current features of Python's object model and 2/
doesn't make any of the currently used "metaprogramming" idioms more
difficult, I just wouldn't care.

castironpi

unread,
Jul 24, 2008, 1:34:40 PM7/24/08
to
On Jul 24, 11:49 am, "Sebastian \"lunar\" Wiesner"
<basti.wies...@gmx.net> wrote:
> Torsten Bronger <bron...@physik.rwth-aachen.de>:

I don't think you can infer from 'explicit is better than implicit'
that 'the more explicit the better'. For instance, we don't use:

python.callbyvalue.foo( bar, 1, 2 )
python.callbyref.foo2( bar, x, y )

or further:

foo( byref bar, byval 1, byval 2 )
foo2( byref bar, byref x, byref x )

though some languages do.

Python doesn't do that much implicity, like copying, with the
exception of copying strings, which some string functions do, such as
lower, replace, strip. (Does slicing return a new string?)

What is the most surprisingly implicit behavior in Python? What is
the most explicit?

Torsten Bronger

unread,
Jul 24, 2008, 1:34:15 PM7/24/08
to
Hallöchen!

Sebastian \"lunar\" Wiesner writes:

> Torsten Bronger <bro...@physik.rwth-aachen.de>:


>
>> Bruno Desthuilliers writes:
>>
>>> Torsten Bronger a écrit :
>>>
>>>> Bruno Desthuilliers writes:
>>>>
>>>> [...]
>>>>

>>>> Just like this. However, the compiler could add "self" to
>>>> non-decorated methods which are defined within "class".
>>>
>>> What's defined within classes are plain functions. It's actually
>>> the lookup mechanism that wraps them into methods (and manage to
>>> insert the current instance as first argument).
>>
>> And why does this make the implicit insertion of "self"
>> difficult? I could easily write a preprocessor which does it
>> after all.
>
> Who said, that it would be "difficult"? He just corrected your
> statement about definitions inside a class, and did not make any
> assumption about making "self" implicit.

If it is not the implementation, I don't see why the "definition
inside a class" matters at all. It can be realised as a
transformation of the syntax tree and would even be transparent for
the compiling steps after it.

Bruno Desthuilliers

unread,
Jul 24, 2008, 12:24:50 PM7/24/08
to
Jordan a écrit :

>> Then why do you write, let me quote:
>>
>> """
>> (snip) coding __eq__ (snip) buys you
>> nothing from the != operator. != isn't (by default) a synonym for the
>> negation of == (unlike in, say, every other language ever); not only
>> will Python let you make them mean different things, without
>> documenting this fact - it actively encourages you to do so.
>> """
>
> My words aren't as clear as they should be. I mean that Python lets
> *you* do something without documenting, or rather stating to use a
> better term, that your intention is the non-obvious one.

> I'm not
> saying that Python itself lacks documentation for its own behaviour;
> I'm saying it should force you to make your intentions clear and
> visible to someone reading your code when you want to do something non-
> obvious.

<nitpick>
One could then answer than, the behaviour of __eq__ / __ne__ being
clearly defined and documented, implementing one without the other - or
in such a way that a != b is different from not(a == b) - is by itself
an explicit 'statement of intention' !-)
</nitpick>

(snip strawmens)

>> Please understand that I'm not arguing about this particular design
>> choice (and FWIW, I'd mostly agree on the point that having a != b
>> different from not (a == b) is actually a wart).
>

> Good, at least we've come to a point in this discussion where I can
> firmly agree with somebody.

On that concrete case, a priori, yes. wrt/ the 'explicit self', there
are in fact two points:

1/ The mandatory use of 'self' to access the current instance.

As far as I'm concerned, and *even if there was no other technical
reasons*, I wholefully, happily and definitively agree with this choice
- specially in a language like Python (it's not quite the same problem
with Java where you just can't put anything outside a class). It's truly
(and IMHO, of course) a case where explicit-is-better-than-implicit,
period.

Strange enough, I never heard of anyone complaining about the mandatory
use of $this-> in PHP. Nor about the mandatory use of @/@@ in Ruby. Nor
about the 'm_whatever' naming convention in C++. Nor about [add your own
example here].

2/ The need to explicitely declare the 'target' object (self or cls) as
first param of a 'function-to-be-used-as-method'.

Granted, this one may feel a bit "unfinished" at first. And I would not
bet my life on it, but I think one could possibly find some "solution"
that would not as a side-effect impose any restriction wrt/ the current
implementation.

OTHO, given 1/, and since the way Python builds "methods" out of just
two more general constructs (the def statement and the descriptor
protocol) is part of what makes it's object model so powerful, I don't
feel like the price to pay to keep the implementation as simple as
possible is too high. IOW, while I would not turn down a "solution" like
the one mentionned above (let's say -0 as far as I'm concerned), I just
don't think it would be worth the time spent.

Anyway, "explicit is better than implicit" is not the appropriate
dogmatic justification here - but a couple other quotes from the
Python's Zen could apply (left as an exercice to the reader) !-)

Bruno Desthuilliers

unread,
Jul 24, 2008, 12:43:25 PM7/24/08
to
Jordan a écrit :

>> I don't really mind, what you think about my response. Python will suffer
>> from it as little as it will suffer from your complaints: These things
>> will not change, whatever any of us says about them. So this discussion
>> unlikely to produce any new insight, especially because this as been
>> discussed over and over again in the past, without any effect on Python.
>
> You're right, of course. Because Python is in so many ways what I'm
> looking for in a language, I transform it in my mind to my own,
> personal ideal, close to the real existing language but with what I
> consider to be the imperfections removed.

I guess you'll find a lot of us guilty here too - but do we really agree
on what we consider to be "imperfections" ?-)

(snip)

> I was trying not to change explicit self, or even != (which has a much
> better case.) I was trying to ask the community to reconsider a
> premise that the language is built around. Explicit is actually kinda
> annoying a lot of the time, viz., java. This is about social and
> philosophical adjustments, not technical ones.
>

"explicit-is-etc" - just like the remaining of Python's zen - is a
general philosophy statement, not an absolute rule. Another quote states
that practicality beats purity.

So yes, Python has warts, and one can't get away dogmatically quoting
Python's zen. Even if I'm sometimes myself guilty here, it's certainly
worth taking time to better address criticism, either by aknowledging
effective warts when someone points them out or by explaining (or
pointing to explanations of) the unusual parts of Python's design.

Now since most of the times, criticisms expressed here fall in the
second category, we're happy to learn you'll now take appropriate action
here and help us keep c.l.py a newbie-friendly place !-)

castironpi

unread,
Jul 24, 2008, 5:34:38 PM7/24/08
to
On Jul 24, 11:43 am, Bruno Desthuilliers

Something that is pure and explicit is a conflict of priorities with
something that is practical and implicit. As with any rules, there
are going to be times when the priorities in the Zen conflict with one
another, and the Zen is silent on which combination ranks higher.

Some people will hate you for using 'sf' instead of 'self'... but some
hate you for spelling errors too. A temper lost is a flamewar earned.

If you post two equivalent code snippets that both work, we can help
you compare them.

Terry Reedy

unread,
Jul 24, 2008, 9:01:58 PM7/24/08
to pytho...@python.org

Torsten Bronger wrote:
> Hallöchen!


> And why does this make the implicit insertion of "self" difficult?
> I could easily write a preprocessor which does it after all.

class C():
def f():
a = 3

Inserting self into the arg list is trivial. Mindlessly deciding
correctly whether or not to insert 'self.' before 'a' is impossible when
'a' could ambiguously be either an attribute of self or a local variable
of f. Or do you and/or Jordan plan to abolish local variables for methods?

tjr

Terry Reedy

unread,
Jul 24, 2008, 9:02:48 PM7/24/08
to pytho...@python.org

Jordan wrote:

> I wish in retrospect I'd had the time, patience and focus to edit the
> initial post to make it more measured and less inflammatory, because
> its clear the tone

I will ignore that.

> detracts from the argument I'm making, which I feel still stands.

class C():
def f():
a = 3

You made a complaint and an incomplete proposal identical to what others
have proposed. But here is where the idea always sinks. Suppose as you
propose 'self' is added to the arg list. How is a mindless algorithm to
decide whether to change a to 'self.a' to make it an attribute or leave
it alone as a local variable? Or would you abolish local vars from
methods (which would slow them down)?

As near as I can see, any concrete detailed implementable proposal would
be a more major change in Python or its implementation than
'down-with-self'ers usually admit.

If the argument you refer to is instead that 'Explicit is better than
Implicit' is a bit overused and inadequate as a technical response, then
I agree. But excuse me for being unsure ;-).

Terry Jan Reedy

Benjamin

unread,
Jul 24, 2008, 10:45:27 PM7/24/08
to
On Jul 24, 11:43 am, Bruno Desthuilliers
<bdesth.quelquech...@free.quelquepart.fr> wrote:
>
> "explicit-is-etc" - just like the remaining of Python's zen - is a
> general philosophy statement, not an absolute rule. Another quote states
> that practicality beats purity.

Very much so. In fact, I'd like you all to take a detour to a recent
bug report [1] where I gained some interesting insight into the Zen.

[1] http://bugs.python.org/issue3364

Lawrence D'Oliveiro

unread,
Jul 25, 2008, 12:33:51 AM7/25/08
to
In message
<8233fbfb-ad9b-43ef...@q5g2000prf.googlegroups.com>, Jordan
wrote:

> On Jul 24, 8:01 pm, Lawrence D'Oliveiro <l...@geek-
> central.gen.new_zealand> wrote:
>
>> In message
>> <52404933-ce08-4dc1-a558-935bbbae7...@r35g2000prm.googlegroups.com>,


>> Jordan wrote:
>>
>> > Except when it comes to Classes. I added some classes to code that had
>> > previously just been functions, and you know what I did - or rather,
>> > forgot to do? Put in the 'self'. In front of some of the variable
>> > accesses, but more noticably, at the start of *every single method
>> > argument list.*
>>
>> The reason is quite simple. Python is not truly an "object-oriented"

>> language. It's sufficiently close to fool those accustomed to OO ways of
>> doing things, but it doesn't force you to do things that way. You still


>> have the choice. An implicit "self" would take away that choice.
>

> You could still explicitly request non-implicit self on a method by
> method basis.

That would mean making OO the default. Which Python doesn't do.

Kay Schluehr

unread,
Jul 25, 2008, 1:06:35 AM7/25/08
to

This isn't the problem Jordan tries to address. It's really just about
`self` in the argument signature of f, not about its omission in the
body. Some problems occur when not `self` shall be used but e.g.
`this`. Here one has to specify more:

class C():
__self__ = 'this' # use `this` instead of `self`
def f(a):
this.a = a

or

class C():
def f($this, a): # use `this` instead of `self`
this.a = a

When an $-prefixed parameter is found the automatic insertion of
`self` will be blocked and the $-prefixed parameter name will be used
instead but without the prefix.

s0s...@gmail.com

unread,
Jul 25, 2008, 2:09:09 AM7/25/08
to
On Jul 24, 5:01 am, Lawrence D'Oliveiro <l...@geek-

central.gen.new_zealand> wrote:
> In message
> <52404933-ce08-4dc1-a558-935bbbae7...@r35g2000prm.googlegroups.com>, Jordan
> wrote:
>
> > Except when it comes to Classes. I added some classes to code that had
> > previously just been functions, and you know what I did - or rather,
> > forgot to do? Put in the 'self'. In front of some of the variable
> > accesses, but more noticably, at the start of *every single method
> > argument list.*
>
> The reason is quite simple. Python is not truly an "object-oriented"
> language. It's sufficiently close to fool those accustomed to OO ways of
> doing things, but it doesn't force you to do things that way. You still
> have the choice. An implicit "self" would take away that choice.

By that logic, C++ is not OO. By that logic, Ruby is not OO. By that
logic, I know of only one OO language: Java :)

The fact that a language doesn't force you to do object-oriented
programming doesn't mean that it's not object-oriented. In other
words, your words are nonsense.

Sebastian

Nikolaus Rath

unread,
Jul 25, 2008, 3:54:30 AM7/25/08
to pytho...@python.org
Terry Reedy <tjr...@udel.edu> writes:
> Torsten Bronger wrote:
>> Hallöchen!

> > And why does this make the implicit insertion of "self" difficult?
>> I could easily write a preprocessor which does it after all.
>
> class C():
> def f():
> a = 3
>
> Inserting self into the arg list is trivial. Mindlessly deciding
> correctly whether or not to insert 'self.' before 'a' is impossible
> when 'a' could ambiguously be either an attribute of self or a local
> variable of f. Or do you and/or Jordan plan to abolish local
> variables for methods?

Why do you think that 'self' should be inserted anywhere except in the
arg list? AFAIU, the idea is to remove the need to write 'self' in the
arg list, not to get rid of it entirely.


Best,

-Nikolaus

--
»It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that.«
-J.H. Hardy

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

cokof...@gmail.com

unread,
Jul 25, 2008, 4:38:30 AM7/25/08
to
>
> By that logic, C++ is not OO. By that logic, Ruby is not OO. By that
> logic, I know of only one OO language: Java :)
>
> The fact that a language doesn't force you to do object-oriented
> programming doesn't mean that it's not object-oriented. In other
> words, your words are nonsense.
>

No, what it means is that it might support OO but doesn't have to, it
isn't the only way to code.

Supporting and Being OO are very different.

s0s...@gmail.com

unread,
Jul 25, 2008, 5:27:34 AM7/25/08
to

"Support OO but it doesn't have to"? That sounds like saying that in
some Python implementations you'll be able to use OO, but that you
just might bump into a Python distribution where you would type

class MClass:
pass

at the interpreter and it would give you an syntax error. Is that what
you mean?

> Supporting and Being OO are very different.

I guess at this point it's rather pointless to discuss this because of
the different and deep level of interpretation that we might have on
the words "support" and "be." IMO, the obvious thing to say is that a
language that *supports* OO can also be said to *be* OO. However, it
would seem just ridiculous to me to say the same thing about a
language like, e.g., Perl, where OO is so pathetic. But maybe this is
just a game of words...

I consider Python to *be* OO, anyway.

Sebastian

Lie

unread,
Jul 25, 2008, 7:49:44 AM7/25/08
to
On Jul 24, 9:26 pm, Jordan <jordanrastr...@gmail.com> wrote:
> In reality? I'll just keep writing Python (hopefully enough so that
> explicit self become burned into muscle memory), and use other
> languages when necessary (no more C than I have to, looking forward to
> dabbling in Erlang soon, and one day overcoming the parentheses phobia
> enough to really tackle Lisp properly). When I'm old enough and wise
> enough, and have the time, energy and inclination, maybe I'll sit down
> and put a proper effort into designing and implementing a new language
> that bests suits my own particular style and needs.

> Just maybe it'll
> be good enough that smart people will rally to defend its design
> principles from people attacking them on the internet :-)

Forgive me in advance, but that is just a day dream, however good a
language design is, there WILL be other people who disagree with the
corner cases. Python is one example, even with Guido that is great at
designing language, there are many edges in python that many people
disagree and attack from time to time, but not every one of those
edges got fixed, why? Because it is impossible to appeal everyone, if
the language is changed according to your (or other's) idea, there
will be some other people who don't like it (with your examples, it
might be the people who are used to functional programming and people
who want to implement a very complex behavior in __eq__ and __ne__).
What seemed to be the obviously correct behavior for you would be
unexpected for some other people (this is also in python's Zen
although in a slightly twisted kind of way[1]: "There should be one--
and preferably only one --obvious way to do it; Although that way may
not be obvious at first unless you're Dutch.").

[1] Basically, the Zen is saying that whether and idea is the
obviously correct way to do something is measured by Guido's measuring
tape. Basically it's also saying that python is designed according to
what HE thinks is obviously correct.

The Zen you're attacking: "Explicit is better than implicit," is a
generally good advice, although as you mentioned, it doesn't fit every
single cases in the world, which leads us to the other Zen[2]:
"Special cases aren't special enough to break the rules; Although
practicality beats purity."

[2] In our case, "Explicit is better than implicit" is the "rules",
the corner cases where implicit is a generally better choice is the
"special cases". The first verse ("Special cases ... break rules")
implies that everything should be explicit, no exceptions, while the
second verse ("practicality beats purity") means that if something
breaking the rule makes it more practical, then you don't have to
follow the rules[3]. These two statements contradicts each other,
implying an implicit Zen: "Foolish consistency is the hobgoblin's
little minds", it is OK to break the rules sometimes.

[3] Despite saying this, I also have to emphasize that what is
practical or not is measured by Guido's tape.

With this explained, I hope you understand the point I'm making:
"There is no The Perfect Language, that is liked by everyone in the
world." The moral is, if you like a language, try to resist its warts
and know that each wart have its own story. You don't have to like the
warts, but you just need to stand to it.

alex23

unread,
Jul 25, 2008, 10:43:17 AM7/25/08
to
On Jul 25, 9:49 pm, Lie <Lie.1...@gmail.com> wrote:
> These two statements contradicts each other,
> implying an implicit Zen: "Foolish consistency is the hobgoblin's
> little minds", it is OK to break the rules sometimes.

"A foolish consistency is _the_ hobgoblin of little minds." (Ralph
Waldo Emerson, although the emphasis is mine)

I do like your version, though :)

Terry Reedy

unread,
Jul 25, 2008, 4:37:26 PM7/25/08
to pytho...@python.org

Kay Schluehr wrote:
> On 25 Jul., 03:01, Terry Reedy <tjre...@udel.edu> wrote:
>> Inserting self into the arg list is trivial. Mindlessly deciding
>> correctly whether or not to insert 'self.' before 'a' is impossible when
>> 'a' could ambiguously be either an attribute of self or a local variable
>> of f. Or do you and/or Jordan plan to abolish local variables for methods?
>>
>> tjr
>
> This isn't the problem Jordan tries to address. It's really just about
> `self` in the argument signature of f, not about its omission in the
> body.

That is not at all how I read him, so I will let him respond if he
wishes. The main problem moving a function from module scope to class
scope is prefixing the proper variables. Adding a param name, whether
'self', 's', 'this', or whatever, is trivial and hardly worth the ink.

Terry Reedy

unread,
Jul 25, 2008, 4:47:47 PM7/25/08
to pytho...@python.org

Nikolaus Rath wrote:
> Terry Reedy <tjr...@udel.edu> writes:
>> Torsten Bronger wrote:
>>> Hallöchen!

>> > And why does this make the implicit insertion of "self" difficult?
>>> I could easily write a preprocessor which does it after all.

>> class C():
>> def f():
>> a = 3
>>

>> Inserting self into the arg list is trivial. Mindlessly deciding
>> correctly whether or not to insert 'self.' before 'a' is impossible
>> when 'a' could ambiguously be either an attribute of self or a local
>> variable of f. Or do you and/or Jordan plan to abolish local
>> variables for methods?
>

> Why do you think that 'self' should be inserted anywhere except in the
> arg list? AFAIU, the idea is to remove the need to write 'self' in the
> arg list, not to get rid of it entirely.

Because you must prefix self attributes with 'self.'. If you do not use
any attributes of the instance of the class you are making the function
an instance method of, then it is not really an instance method and need
not and I would say should not be masqueraded as one. If the function
is a static method, then it should be labeled as one and no 'self' is
not needed and auto insertion would be a mistake. In brief, I assume
the OP wants 'self' inserted in the body because inserting it only in
the parameter list and never using it in the body is either silly or wrong.

tjr

Fuzzyman

unread,
Jul 25, 2008, 6:08:20 PM7/25/08
to
On Jul 24, 6:41 am, Jordan <jordanrastr...@gmail.com> wrote:
> Hi everyone,
>
> I'm a big Python fan who used to be involved semi regularly in
> comp.lang.python (lots of lurking, occasional posting) but kind of
> trailed off a bit. I just wrote a frustration inspired rant on my
> blog, and I thought it was relevant enough as a wider issue to the
> Python community to post here for your discussion and consideration.
>
> This is not flamebait. I love Python, and I'm not out to antagonise
> the community. I also realise that one of the issues I raise is way
> too ingrained to be changed now. I'd just like to share my thinking on
> a misstep in Python's guiding principles that has done more harm than
> good IMO. So anyway, here's the post.
>
> I've become utterly convinced that at least one criticism leveled at
> my favourite overall programming language, Python, is utterly true and
> fair. After quite a while away from writing Python code, I started
> last night on a whim to knock up some code for a prototype of an idea
> I once had. It's going swimmingly; the Python Image Library, which I'd
> never used before, seems quick, intuitive, and with the all the
> features I need for this project. As for Python itself, well, my heart
> still belongs to whitespace delimitation. All the basics of Python
> coding are there in my mind like I never stopped using them, or like
> I've been programming in this language for 10 years.

>
> Except when it comes to Classes. I added some classes to code that had
> previously just been functions, and you know what I did - or rather,
> forgot to do? Put in the 'self'. In front of some of the variable
> accesses, but more noticably, at the start of *every single method
> argument list.* This cannot be any longer blamed as a hangover from
> Java - I've written a ton more code, more recently in Python than in
> Java or any other OO language. What's more, every time I go back to
> Python after a break of more than about a week or so, I start making
> this 'mistake' again. The perennial justification for this 'feature'
> of the language? That old Python favourite, "Explicit is better than
> implicit."
>


It's damn useful for scoping. You can look in the body of your method
and tell whether you are accessing local variables or instance
variables.

I'm a great fan of self and I'm afraid you're flogging a dead horse on
that one.

Your point about rich comparison (at least the == != problem) is fair.
This one is fixed in Python 3 though I believe.

Michael Foord
--
http://www.ironpythoninaction.com/

Paul Boddie

unread,
Jul 25, 2008, 6:32:44 PM7/25/08
to
On 25 Jul, 22:37, Terry Reedy <tjre...@udel.edu> wrote:

> Kay Schluehr wrote:
> >
> > This isn't the problem Jordan tries to address. It's really just about
> > `self` in the argument signature of f, not about its omission in the
> > body.
>
> That is not at all how I read him, so I will let him respond if he
> wishes. The main problem moving a function from module scope to class
> scope is prefixing the proper variables. Adding a param name, whether
> 'self', 's', 'this', or whatever, is trivial and hardly worth the ink.

He wrote the following of relevance:

"I added some classes to code that had previously just been functions,
and you know what I did - or rather, forgot to do? Put in the 'self'.
In front of some of the variable accesses, but more noticably, at the
start of *every single method argument list.*"

And rounding off with this on the subject:

"The problem is that the explicit requirement to have self at the
start
of every method is something that should be shipped off to the
implicit category."

I guess the desire is to have Java-like behaviour: when defining a
method, which must typically be done in the class definition in Java
(unless they've enhanced that area in the past few years), you never
write a "this" parameter in the method signature, but you are free to
qualify instance attribute accesses with "this". Personally, I liked
the Modula-3-inspired requirement for "self" in Python, but I can see
how a reminder of what it is in every method signature (defined within
a class) might be regarded as overly explicit.

Paul

Colin J. Williams

unread,
Jul 25, 2008, 7:44:28 PM7/25/08
to
> Your point about rich comparison (at least the == != problem) is fair..

> This one is fixed in Python 3 though I believe.
>
> Michael Foord
> --
> http://www.ironpythoninaction.com/

I hope that the OP will develop some
specific proposal, narrowly focused on
the "self" issue.

It has always seemed redundant on the
argument line of a definition. It does
permit one to use some other word but is
that of any real value.

One can still use self.a= 'z' or perhaps
.a= 'z'.

Colin W.

Jordan

unread,
Jul 25, 2008, 10:49:57 PM7/25/08
to
Well this discussion is chugging along merrily now under its own
steam, but as the OP I should probably clarify a few things about my
own views since people continue to respond to them (and are in some
cases misunderstanding me.)

I *like* explicit self for instance variable access. There are
arguments for and against, and my personal opinion is that the
arguments for are stronger. Local variables and instance variables
should be explicitly differentiated somehow, for the sake of
readability. Python's approach works. I slightly prefer Ruby's @,
because I think the brevity is a net win for something so commonplace
(is it less readable? Maybe. is "def" less readable than "define"? I
don't know - I think about 10 seconds of coding in Python or Ruby is
enough for you to be able to instantly grok def. Likewise, @. The
argument is more aesthetic IMO - how many perl-style/1337speak pu|\|
(tu@t10n m@r|<$ can you stand?)

I have come to dislike explicit self in method argument lists. Sure,
there are reasons. I don't think they're at all strong enough.

I'm definitely against the != behaviour, and maybe will get around to
actually PEPing it.

The point I was trying to make originally was that applying any mantra
dogmatically, including Explicit is better than implicit, can lead to
bad results. Perhaps having Practicality beats purity is enough of a
reminder of that fact for the Python community :-)

Terry Reedy

unread,
Jul 26, 2008, 12:06:05 AM7/26/08
to pytho...@python.org

Paul Boddie wrote:
> On 25 Jul, 22:37, Terry Reedy <tjre...@udel.edu> wrote:
>> Kay Schluehr wrote:
>>> This isn't the problem Jordan tries to address. It's really just about
>>> `self` in the argument signature of f, not about its omission in the
>>> body.
>> That is not at all how I read him, so I will let him respond if he
>> wishes. The main problem moving a function from module scope to class
>> scope is prefixing the proper variables. Adding a param name, whether
>> 'self', 's', 'this', or whatever, is trivial and hardly worth the ink.
>
> He wrote the following of relevance:
>
> "I added some classes to code that had previously just been functions,
> and you know what I did - or rather, forgot to do? Put in the 'self'.
> In front of some of the variable accesses, but more noticably, at the
> start of *every single method argument list.*"
>
> And rounding off with this on the subject:
>
> "The problem is that the explicit requirement to have self at the
> start
> of every method is something that should be shipped off to the
> implicit category."

There is no requirement to have 'self' in the parameter list. It can be
's', 'this', 'me', 'yo'(Spanish for I), or 'cls' (for class methods), or
any other identifier in whatever language.
In 3.0, identifiers are not restricted to ascii but can be any unicode
'word' as defined in the manual.

So the proposal would have to be that the compiler scan the function
body and decide which dotted name prefix is the one to be implicitly
added. Have fun writing the discovery algorithm. However, I think this
is pretty silly. Just write the name you want.

Or the proposal would have to be that 'self' is mandatory for all
programmers in all languages. I think *that* would be pernicious.
People are now free to write the more compact 's.sum = s.a + s.b + s.c'
if they want instead of the 'self' version. And again, not everyone
writes in English.

tjr

Matthew Fitzgibbons

unread,
Jul 26, 2008, 12:43:45 AM7/26/08
to pytho...@python.org
> --
> http://mail.python.org/mailman/listinfo/python-list
>


Having followed this entire discussion, I don't think that explicit vs.
implicit is really the issue. Your own examples, self in the arg list
and __ne__ not being the negation of __eq__ by default, seem to
contradict your premise that explicit is dogmatically favored over implicit.

Keep in mind that another core principle of Python is "don't make the
user type it if they don't have to." As you yourself admit, there are
very compelling reasons to make the user type self in every method
argument list, one of which being yet another Python principle,
readability. Therefore, explicit self didn't come through dogmatic
adherence to explicit over implicit, but through careful consideration.

As for !=, it seems like there is a technical reason for the behavior.
Remember, there is no default __ne__ method, so the behavior you want
would have to live in the interpreter. If __ne__ isn't defined, it would
have to try to call __eq__ and negate the result. Is there any other
lookup that is treated this way? It seems like a kludge to add this
special type of behavior for one case that doesn't seem to bother most
people anyway.

So really, this is about a couple annoyances you've found in a language
you otherwise like. And it seems like both can be addressed pretty
easily. PyLint, for example, already checks that self is the first
argument of methods. And since it has a plugin system, I'm sure you
could add a check for __ne__ if __eq__ is defined. You can turn off the
checks you don't care about and bind it to a key combo in your text
editor. Those annoying little errors will be exposed very quickly.

-Matt

Torsten Bronger

unread,
Jul 26, 2008, 3:45:21 AM7/26/08
to
Hallöchen!

Terry Reedy writes:

> [...]


>
> Or the proposal would have to be that 'self' is mandatory for all
> programmers in all languages. I think *that* would be
> pernicious. People are now free to write the more compact 's.sum =
> s.a + s.b + s.c' if they want instead of the 'self' version. And
> again, not everyone writes in English.

Of course, "self" would have to become a reserved word. You could
say that this may break some code, but I don't see much freedom
removed from the language. After all, being a German, I still can't
write "Für i in range(10)". ;-)

Carl Banks

unread,
Jul 26, 2008, 3:51:00 AM7/26/08
to
On Jul 24, 4:11 am, Jordan <jordanrastr...@gmail.com> wrote:
> Of course not.
>
> I just think Explicit is better than Implicit is taken seriously by a
> large segment the Python community as a guiding principle,

Yeah, try telling that to the people who advise writing "if x" instead
of "if x==0", or "if s" instead of "if len(s)==0".


Carl Banks

Carl Banks

unread,
Jul 26, 2008, 4:19:05 AM7/26/08
to
On Jul 24, 1:41 am, Jordan <jordanrastr...@gmail.com> wrote:
> Except when it comes to Classes. I added some classes to code that had

> previously just been functions, and you know what I did - or rather,
> forgot to do? Put in the 'self'. In front of some of the variable
> accesses, but more noticably, at the start of *every single method
> argument list.* This cannot be any longer blamed as a hangover from
> Java - I've written a ton more code, more recently in Python than in
> Java or any other OO language. What's more, every time I go back to
> Python after a break of more than about a week or so, I start making
> this 'mistake' again. The perennial justification for this 'feature'
> of the language? That old Python favourite, "Explicit is better than
> implicit."

I'm sure some people use that argument, but in my observations the
more common justification for explicit self is that makes code easier
to read, by making it obvious that something is a class attribute
instead of a local or global variable.

Your claim is that self makes code a lot harder to write, but you've
disregarded the viewpoint of the reader altogether. You probably are
aware that there is another Zen that says "Readability Counts". Would
you also suggest that Zen needs to be done away with?


> If there was one change I could make to Python, it would be to get
> that damn line out of the Zen.

Personally, I think you've applied it to things that it wasn't really
intended for. It's mostly applies to things like language syntax,
type conversions, and other semantics. For instance in Perl there are
cases where you can omit quotes around strings; that'd be a major no-
no in Python. Or how about this:

a = 1 # a is an integer
a += "hello" # oops, now it's a string

Let me suggest that such things are a Very Bad Idea and so that line
is better left in place.


Carl Banks

Bruno Desthuilliers

unread,
Jul 26, 2008, 3:34:43 AM7/26/08
to
Carl Banks a écrit :

Anyone suggesting that 'if x' should be replaced by 'if x==0' should be
shot down before he even get a chance to write any code. But perhaps you
meant replacing 'if x' by 'if x != 0' and 'if s' by 'if len(s) != 0' ?-)

Bruno Desthuilliers

unread,
Jul 26, 2008, 3:58:39 AM7/26/08
to
Matthew Fitzgibbons a écrit :
(snip)

> As for !=, it seems like there is a technical reason for the behavior.
> Remember, there is no default __ne__ method, so the behavior you want
> would have to live in the interpreter. If __ne__ isn't defined, it would
> have to try to call __eq__ and negate the result. Is there any other
> lookup that is treated this way?

There are quite a few cases in Python where there are both a specific
magic method *and* a default behaviour based on another magic method if
the specific one is not implemented. Just out of my mind:
* __contains__ and __getitem__
* __iter__ and __getitem__
* __nonzero__ and __len__

Not to mention the fact that lookup rules even check the existence of
special methods on class attributes (remember the descriptor protocol ?)...

Nikolaus Rath

unread,
Jul 26, 2008, 5:08:12 AM7/26/08
to pytho...@python.org


I think you misunderstood him. What he wants is to write


class foo:
def bar(arg):
self.whatever = arg + 1


instead of

class foo:
def bar(self, arg)
self.whatever = arg + 1


so 'self' should *automatically* only be inserted in the function
declaration, and *manually* be typed for attributes.

Bruno Desthuilliers

unread,
Jul 26, 2008, 8:05:39 AM7/26/08
to
Bruno Desthuilliers a écrit :
(snip)

> There are quite a few cases in Python where there are both a specific
> magic method *and* a default behaviour based on another magic method if
> the specific one is not implemented. Just out of my mind:

s/out of my mind/Off the top of my head/

Pardon my french, and thanks to Tim Golden for the correction !-)


Steven D'Aprano

unread,
Jul 26, 2008, 8:24:28 AM7/26/08
to
On Sat, 26 Jul 2008 11:08:12 +0200, Nikolaus Rath wrote:

> Terry Reedy <tjr...@udel.edu> writes:
...


>> Because you must prefix self attributes with 'self.'. If you do not use
>> any attributes of the instance of the class you are making the function
>> an instance method of, then it is not really an instance method and
>> need not and I would say should not be masqueraded as one. If the
>> function is a static method, then it should be labeled as one and no
>> 'self' is not needed and auto insertion would be a mistake. In brief, I
>> assume the OP wants 'self' inserted in the body because inserting it
>> only in the parameter list and never using it in the body is either
>> silly or wrong.
>
>
> I think you misunderstood him. What he wants is to write
>
>
> class foo:
> def bar(arg):
> self.whatever = arg + 1
>
>
> instead of
>
> class foo:
> def bar(self, arg)
> self.whatever = arg + 1
>
>
> so 'self' should *automatically* only be inserted in the function
> declaration, and *manually* be typed for attributes.


That idea might have worked many years ago, but not now. The problem is,
what happens here?

class Foo(object):
def foo(self, arg):


self.whatever = arg + 1

@classmethod
def cfoo(cls, arg):
cls.whatever = arg - 1
@staticmethod
def sfoo(arg):
print arg


How does the compiler know to insert "self" into the argument list for
foo, "cls" into that of cfoo, but do nothing for sfoo? Decorators can
transform methods in arbitrarily complex ways using the Descriptor
protocol.


--
Steven

Torsten Bronger

unread,
Jul 26, 2008, 8:40:00 AM7/26/08
to
Hallöchen!

Steven D'Aprano writes:

> On Sat, 26 Jul 2008 11:08:12 +0200, Nikolaus Rath wrote:
>

>> [...]


>>
>> so 'self' should *automatically* only be inserted in the function
>> declaration, and *manually* be typed for attributes.
>
>
> That idea might have worked many years ago, but not now. The
> problem is, what happens here?
>
> class Foo(object):
> def foo(self, arg):
> self.whatever = arg + 1
> @classmethod
> def cfoo(cls, arg):
> cls.whatever = arg - 1
> @staticmethod
> def sfoo(arg):
> print arg

See <news:874p6fz...@physik.rwth-aachen.de>. It is only added
to non-decorated methods within a class. This implies that you can
switch this mechanism off with a noop decorator.

D'Arcy J.M. Cain

unread,
Jul 26, 2008, 10:11:13 AM7/26/08
to Torsten Bronger, pytho...@python.org
On Sat, 26 Jul 2008 09:45:21 +0200
Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
> Of course, "self" would have to become a reserved word. You could
> say that this may break some code, but I don't see much freedom

Isn't this a showstopper all by itself?

> removed from the language. After all, being a German, I still can't
> write "Für i in range(10)". ;-)

Yes, this is why good languages try to limit the number of reserved
words as much as possible.

--
D'Arcy J.M. Cain <da...@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

Torsten Bronger

unread,
Jul 26, 2008, 10:25:18 AM7/26/08
to
Hallöchen!

D'Arcy J.M. Cain writes:

> On Sat, 26 Jul 2008 09:45:21 +0200
> Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>
>> Of course, "self" would have to become a reserved word. You
>> could say that this may break some code, but I don't see much
>> freedom
>
> Isn't this a showstopper all by itself?

Yes. But I've seen no code that uses some other word. Emacs'
syntax highlighting even treats it as reserved. So I think that
other counter-arguments are stronger.

The in my opinion strongest one is that automatic insertion of
"self" would make Python less verbose but more complicated.

D'Arcy J.M. Cain

unread,
Jul 26, 2008, 10:36:30 AM7/26/08
to Torsten Bronger, pytho...@python.org
On Sat, 26 Jul 2008 16:25:18 +0200
Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
> > Isn't this a showstopper all by itself?
>
> Yes. But I've seen no code that uses some other word. Emacs'
> syntax highlighting even treats it as reserved. So I think that
> other counter-arguments are stronger.
>
> The in my opinion strongest one is that automatic insertion of
> "self" would make Python less verbose but more complicated.

Well, if we are arguing over which reason to not change it is more
important than I would say that we are in "violent agreement." :-)

Torsten Bronger

unread,
Jul 26, 2008, 10:47:32 AM7/26/08
to
Hallöchen!

D'Arcy J.M. Cain writes:

> On Sat, 26 Jul 2008 16:25:18 +0200
> Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>
>>> Isn't this a showstopper all by itself?
>>
>> Yes. But I've seen no code that uses some other word. Emacs'
>> syntax highlighting even treats it as reserved. So I think that
>> other counter-arguments are stronger.
>>
>> The in my opinion strongest one is that automatic insertion of
>> "self" would make Python less verbose but more complicated.
>
> Well, if we are arguing over which reason to not change it is more
> important than I would say that we are in "violent agreement."
> :-)

Oh, I've never been in favour of the change
(news:87zlo7y...@physik.rwth-aachen.de). I just don't think
that some popular counter-arguments are compelling. ;-)

Kay Schluehr

unread,
Jul 26, 2008, 11:20:51 AM7/26/08
to
On 26 Jul., 09:45, Torsten Bronger <bron...@physik.rwth-aachen.de>
wrote:

> Hallöchen!
>
> Terry Reedy writes:
> > [...]
>
> > Or the proposal would have to be that 'self' is mandatory for all
> > programmers in all languages. I think *that* would be
> > pernicious. People are now free to write the more compact 's.sum =
> > s.a + s.b + s.c' if they want instead of the 'self' version. And
> > again, not everyone writes in English.
>
> Of course, "self" would have to become a reserved word.

??

This is an extra requirement. Why do you want to make 'self' a keyword?

Torsten Bronger

unread,
Jul 26, 2008, 11:22:55 AM7/26/08
to
Hallöchen!

Kay Schluehr writes:

How could one determine which other identifier must be inserted into
the method's signature?

Aahz

unread,
Jul 26, 2008, 11:28:21 AM7/26/08
to
In article <5845bf4f-65bf-4a36...@q28g2000prh.googlegroups.com>,

Jordan <jordanr...@gmail.com> wrote:
>
>The point I was trying to make originally was that applying any mantra
>dogmatically, including Explicit is better than implicit, can lead to
>bad results. Perhaps having Practicality beats purity is enough of a
>reminder of that fact for the Python community :-)

IMO, you made a big mistake in combining your point with two other meaty
issues (whether method definitions should include self and whether !=
should use __eq__() as a fallback). Moreover, your point is IMO not
sufficiently proven (that is, I see little evidence that Python
development follows any one point of the Zen of Python dogmatically).

You should therefore not be particularly surprised that the discussion
has gone sideways to your intentions -- especially when you start with a
flamebait Subject: line of "attacking sacred cows"! If solid discussion
is your goal, I suggest that you wait a couple of weeks and start over
with a brand-new thread.
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!

Michele Simionato

unread,
Jul 26, 2008, 1:20:43 PM7/26/08
to
On Jul 26, 5:28 pm, a...@pythoncraft.com (Aahz) wrote:
> IMO, you made a big mistake in combining your point with two other meaty
> issues (whether method definitions should include self and whether !=
> should use __eq__() as a fallback).
<snip>

>  If solid discussion
> is your goal, I suggest that you wait a couple of weeks and start over
> with a brand-new thread.

I fully subscribe this. The point about __eq__ is legitimate and could
be discussed with quite tones.
I was bitten by this surprising behavior just a few
days ago, I had defined __eq__ and I expected __neq__
to be defined in the obvious way. I saw that it was
not the case and I figured out immediately that
I had to override __neq__ explicitely (I have
the "explicit is better than implicit" mantra
ingrained in my mind too), I did so and everything
worked out as a charm. Total time loss: five minutes.
So, it is not a big point. Still I think
that it would make sense to automatically
define __neq__ as the negation of __eq__.
I suppose the developers did not want to make a special
case in the implementation and this is also a legitimate
concern.

Michele Simionato

Paul Boddie

unread,
Jul 26, 2008, 2:22:59 PM7/26/08
to
On 26 Jul, 06:06, Terry Reedy <tjre...@udel.edu> wrote:

> Paul Boddie wrote:
> > "The problem is that the explicit requirement to have self at the
> > start of every method is something that should be shipped off to the
> > implicit category."

Here, I presume that the author meant "at the start of every method
signature".

> There is no requirement to have 'self' in the parameter list. It can be
> 's', 'this', 'me', 'yo'(Spanish for I), or 'cls' (for class methods), or
> any other identifier in whatever language.

But Jordan apparently wanted to omit that parameter. The omission of
all mentions of "self" could be regarded as a bonus, but it's a non-
trivial goal.

> In 3.0, identifiers are not restricted to ascii but can be any unicode
> 'word' as defined in the manual.
>
> So the proposal would have to be that the compiler scan the function
> body and decide which dotted name prefix is the one to be implicitly
> added. Have fun writing the discovery algorithm. However, I think this
> is pretty silly. Just write the name you want.

If, as I wrote, you permit the omission of "self" in method signatures
defined within class definitions, then you could still insist on
instance attribute qualification using "self" - exactly as one would
when writing Java according to certain style guidelines.

Paul

Russ P.

unread,
Jul 26, 2008, 3:48:33 PM7/26/08
to

> If, as I wrote, you permit the omission of "self" in method signatures
> defined within class definitions, then you could still insist on
> instance attribute qualification using "self" - exactly as one would
> when writing Java according to certain style guidelines.

I'm not sure exactly what people mean here by allowing "self" to be
"omitted" in method signatures. If it is omitted, then it seems to me
that a place holder would be needed to the interpreter that the first
argument is not just another name for "self."

In an earlier post on this thread (don't feel like looking it up at
the moment), someone suggested that member data could be accessed
using simply ".member". I think he might be on to something. The dot
is a minimal indicator that the data is a class member rather than
just local. However, a placeholder is still needed in the signature.

So why not allow something like this?:

class MyClass:

def func( , xxx, yyy):

.xxx = xxx

local = .yyy

The "self" argument is replaced with nothing, but a comma is used as a
placeholder.

Colin J. Williams

unread,
Jul 26, 2008, 5:03:49 PM7/26/08
to Russ P.
(+1) but why retain the leading comma in
the argument list?

Colin W.

Terry Reedy

unread,
Jul 26, 2008, 5:07:13 PM7/26/08
to pytho...@python.org

Whether or not one should write 'if x' or 'if x != 0' [typo corrected]
depends on whether one means the general 'if x is any non-null object
for which bool(x) == True' or the specific 'if x is anything other than
numeric zero'. The two are not equivalent. Ditto for the length example.

What people do properly advise against is the strictly redundant 'if x
is True' or 'if x == True'. Both imply a misunderstanding of how 'if'
works in Python.

As a side note, the usefulness of specific comparisons is greater in 3.0
where spurious comparisons raise exceptions. In 3.0, 'if x >= 0'
specifically means 'if x is a number comparable to ints that is greater
than or equal to 0'. In 3.0, [] ==/!= 0 are still False/True, but one
could exclude incomparables with 'if 0 <= x >= 0' (==0) or 'if x > 0 or
x < 0' (!=0). Any such specific comparisons could be used with this
pattern.

try:
x = []
if x >= 0:
print('should not get here')
except TypeError as m:
if m.args[0].startswith('unorderable types:'):
print('Here because of bad comparison')

Terry Jan Reedy

Russ P.

unread,
Jul 26, 2008, 5:16:42 PM7/26/08
to

> > So why not allow something like this?:
>
> > class MyClass:
>
> > def func( , xxx, yyy):
>
> > .xxx = xxx
>
> > local = .yyy
>
> > The "self" argument is replaced with nothing, but a comma is used as a
> > placeholder.
>
> (+1) but why retain the leading comma in
> the argument list?

As I said, the leading comma is a place holder. Without it, the
interpreter would have no way of knowing that the first argument is


not just another name for "self."

We need to maintain compatibility with existing Python rules. If we
were designing a new language, we could omit the "self" argument in
the signature, and allow either ".xxx" or "self.xxx," at the
programmers discretion (i.e., let "self" be the standard name, like
"this" in C++).

Terry Reedy

unread,
Jul 26, 2008, 5:17:09 PM7/26/08
to pytho...@python.org

Torsten Bronger wrote:
> Hallöchen!
>
> Terry Reedy writes:
>
>> [...]
>>
>> Or the proposal would have to be that 'self' is mandatory for all
>> programmers in all languages. I think *that* would be
>> pernicious. People are now free to write the more compact 's.sum =
>> s.a + s.b + s.c' if they want instead of the 'self' version. And
>> again, not everyone writes in English.
>
> Of course, "self" would have to become a reserved word. You could
> say that this may break some code,

Will break.

> but I don't see much freedom removed from the language.
> After all, being a German, I still can't
> write "Für i in range(10)". ;-)

But you can write 'for ubermenchen in range(10):' and in 3.0, with
diacritics added. Would you really feel no loss of freedom if Guido
make i0, i1, ... into keywords, which means they could not be used
elsewhere, and mandated them as for loop index variables?

Terry Reedy

unread,
Jul 26, 2008, 5:19:59 PM7/26/08
to pytho...@python.org

Nikolaus Rath wrote:
>
> I think you misunderstood him.

I did, but addressed the below in another post.

> What he wants is to write
>

> class foo:
> def bar(arg):


> self.whatever = arg + 1
>

> instead of
>
> class foo:
> def bar(self, arg)


> self.whatever = arg + 1
>

> so 'self' should *automatically* only be inserted in the function
> declaration, and *manually* be typed for attributes.

which means making 'self' a keyword just so it can be omitted. Silly
and pernicious.

tjr

Terry Reedy

unread,
Jul 26, 2008, 5:25:02 PM7/26/08
to pytho...@python.org

Torsten Bronger wrote:
> Hallöchen!
>
> D'Arcy J.M. Cain writes:
>
>> On Sat, 26 Jul 2008 09:45:21 +0200
>> Torsten Bronger <bro...@physik.rwth-aachen.de> wrote:
>>
>>> Of course, "self" would have to become a reserved word. You
>>> could say that this may break some code, but I don't see much
>>> freedom
>> Isn't this a showstopper all by itself?
>
> Yes. But I've seen no code that uses some other word.

There is a lot of code you have not seen. Really. In informal code I
use 's' and 'o' for 'self' and 'other'. I don't usually post such
because it is not considered polite. So you have seen a biased sample
of the universe.

Torsten Bronger

unread,
Jul 26, 2008, 5:35:22 PM7/26/08
to
Hallöchen!

Terry Reedy writes:

> Torsten Bronger wrote:
>
>> Terry Reedy writes:
>>
>>> [...]
>>>
>>> Or the proposal would have to be that 'self' is mandatory for
>>> all programmers in all languages. I think *that* would be
>>> pernicious. People are now free to write the more compact 's.sum
>>> = s.a + s.b + s.c' if they want instead of the 'self' version.
>>> And again, not everyone writes in English.
>>
>> Of course, "self" would have to become a reserved word. You
>> could say that this may break some code,
>
> Will break.

No more than Python 3.0 breaks.

>> but I don't see much freedom removed from the language. After
>> all, being a German, I still can't write "Für i in range(10)".
>> ;-)
>
> But you can write 'for ubermenchen in range(10):' and in 3.0, with
> diacritics added. Would you really feel no loss of freedom if
> Guido make i0, i1, ... into keywords, which means they could not
> be used elsewhere, and mandated them as for loop index variables?

I would, but I consider "self" becoming a keyword not even in the
same league as i0, i1 etc.

Terry Reedy

unread,
Jul 26, 2008, 5:49:17 PM7/26/08
to pytho...@python.org

Paul Boddie wrote:
> On 26 Jul, 06:06, Terry Reedy <tjre...@udel.edu> wrote:
>> Paul Boddie wrote:
>>> "The problem is that the explicit requirement to have self at the
>>> start of every method is something that should be shipped off to the
>>> implicit category."
>
> Here, I presume that the author meant "at the start of every method
> signature".
>
>> There is no requirement to have 'self' in the parameter list. It can be
>> 's', 'this', 'me', 'yo'(Spanish for I), or 'cls' (for class methods), or
>> any other identifier in whatever language.
>
> But Jordan apparently wanted to omit that parameter. The omission of
> all mentions of "self" could be regarded as a bonus, but it's a non-
> trivial goal.

Reword. There is no requirement to name the instance anything in
particular. Thus there is no requirement at present that the first
parameter, which gives the name of the instance, be anything in
particular.

>> In 3.0, identifiers are not restricted to ascii but can be any unicode
>> 'word' as defined in the manual.
>>
>> So the proposal would have to be that the compiler scan the function
>> body and decide which dotted name prefix is the one to be implicitly
>> added. Have fun writing the discovery algorithm. However, I think this
>> is pretty silly. Just write the name you want.
>
> If, as I wrote, you permit the omission of "self" in method signatures
> defined within class definitions, then you could still insist on
> instance attribute qualification using "self" - exactly as one would
> when writing Java according to certain style guidelines.

Which is what I said in the first sentence of my next paragraph, which
you clipped.


"Or the proposal would have to be that 'self' is mandatory for all

programmers in all languages." To clarify " ... that 'self' be the
mandatory instance name for all Python programmers regardless of
inclination or the natural language they otherwise use as a basis for
identifiers."

In sum, if the instance name is omitted from the parameter list, it must
either be discovered or mandated, and def statements in direct class
scope have to be treated differently from def statements elsewhere.

Terry Jan Reedy

Torsten Bronger

unread,
Jul 26, 2008, 5:49:29 PM7/26/08
to
Hallöchen!

Terry Reedy writes:

I didn't say that no code breaks, nor that I've analysed more than
0.1% of the global Python code. But still, this doesn't convice me.
I still think that only a very small fraction of Python code would
break. Since no one can make a global analysis, it is more sensible
to compare it with the amount of code broken by Python 3.0 in my
opinion.

Carl Banks

unread,
Jul 26, 2008, 6:58:16 PM7/26/08
to
On Jul 26, 5:07 pm, Terry Reedy <tjre...@udel.edu> wrote:
> Whether or not one should write 'if x' or 'if x != 0' [typo corrected]
> depends on whether one means the general 'if x is any non-null object
> for which bool(x) == True' or the specific 'if x is anything other than
> numeric zero'.  The two are not equivalent.  Ditto for the length example.

Can you think of any use cases for the former? And I mean something
where it can't be boiled down to a simple explicit test for the sorts
of arguments you're expecting; something that really takes advantage
of the "all objects are either true or false" paradigm.

The best thing I can come up with out of my mind is cases where you
want to check for zero or an empty sequence, and you want to accept
None as an alternative negative as well. But that's pretty weak.

The use case of simply passing something to a function that accepts
any boolean doesn't count. For instance, I could write:

def nand(a,b):
return not (a and b)

And then I could use it like this, even if x is an interger and y a
string:

if nand(x,y):

But that doesn't buy much since I could just pass in the explicit
tests like this:

if nand(x!=0,y!=""):


Carl Banks

Lawrence D'Oliveiro

unread,
Jul 26, 2008, 7:47:30 PM7/26/08
to
In message
<024ace13-f72f-4093...@v1g2000pra.googlegroups.com>,
s0s...@gmail.com wrote:

> On Jul 24, 5:01 am, Lawrence D'Oliveiro <l...@geek-
> central.gen.new_zealand> wrote:
>
>> In message
>> <52404933-ce08-4dc1-a558-935bbbae7...@r35g2000prm.googlegroups.com>,
>> Jordan wrote:
>>
>> > Except when it comes to Classes. I added some classes to code that had
>> > previously just been functions, and you know what I did - or rather,
>> > forgot to do? Put in the 'self'. In front of some of the variable
>> > accesses, but more noticably, at the start of *every single method
>> > argument list.*
>>
>> The reason is quite simple. Python is not truly an "object-oriented"
>> language. It's sufficiently close to fool those accustomed to OO ways of
>> doing things, but it doesn't force you to do things that way. You still
>> have the choice. An implicit "self" would take away that choice.
>
> By that logic, C++ is not OO.

Yes it is, because it has "this".

Lawrence D'Oliveiro

unread,
Jul 26, 2008, 7:48:12 PM7/26/08
to
In message
<43d32584-e762-4578...@k36g2000pri.googlegroups.com>,
s0s...@gmail.com wrote:

> "Support OO but it doesn't have to"? That sounds like saying that in
> some Python implementations you'll be able to use OO, but that you
> just might bump into a Python distribution ...

Change "distribution" to "program" and you're on the right track.

Russ P.

unread,
Jul 26, 2008, 8:14:46 PM7/26/08
to
On Jul 26, 2:25 pm, Terry Reedy

> There is a lot of code you have not seen. Really. In informal code I
> use 's' and 'o' for 'self' and 'other'. I don't usually post such
> because it is not considered polite. So you have seen a biased sample
> of the universe.

You take the name down to a single letter. As I suggested in an
earlier post on this thread, why not take it down to zero letters? You
could if Python accepted something like

class Whatever:

def fun( , cat):

.cat = cat

This is even better than the single-character name, not only because
it is shorter, but also because there is no question that you are
referring to "self." No need to look back at the method signature to
verify that.

For those who don't like the way the empty first argument looks, maybe
something like this could be allowed:

def fun( ., cat):

Marcus.CM

unread,
Jul 26, 2008, 10:23:06 PM7/26/08
to pytho...@python.org
Well after reading some of these posts on "sacred python cow" on the
"self" , i would generally feel that most programmers
who started with C++/Java would find it odd. And its true, i agree
completely there should not be a need to put "self" into every single
member function. If you were writing an application and one of your
classes adds the same variable to each of its member function you would
do away with it too.
What could be done instead is :-

1. python should hardcode the keyword "self". So whenever this keyword
is used, it would automatically implied that it is
referring to a class scope variable. This would be similar to how the
"this" keyword is used in C++.

2. Omit self from the parameter.

class Abc :
def DoSomething (a,b,c) :
# class variable
self.somevar = a
self.someblar = b
self.somec = c
somevar = a * b # local variable

> --
> http://mail.python.org/mailman/listinfo/python-list
>
>


Russ P.

unread,
Jul 26, 2008, 11:21:17 PM7/26/08
to
On Jul 26, 7:23 pm, "Marcus.CM"

> 1. python should hardcode the keyword "self". So whenever this keyword
> is used, it would automatically implied that it is
> referring to a class scope variable. This would be similar to how the
> "this" keyword is used in C++.
>
> 2. Omit self from the parameter.

That might make sense if you're starting from scratch on a new
language, but it is not compatible with Python as it is currently
stands. Yes, it could have been put into 3.0, but it's way too late
now for a change that drastic.

Beyond that, I don't like the idea of being forced to use "self" in
every case. Yes, C++ and Java standardized on "this," but it is
implied and is usually not explicitly needed.

s0s...@gmail.com

unread,
Jul 27, 2008, 12:46:31 AM7/27/08
to
On Jul 26, 6:47 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> In message
> <024ace13-f72f-4093-bcc9-f8a339c32...@v1g2000pra.googlegroups.com>,

You mean the keyword "this"? It's just a feature. How does that make a
difference on being or not being OO?

(It's true that C++ has more OO features than Python, like private/
public members, virtual methods, etc. But I don't see how a trivial
feature like an additional keyword makes a difference.)

Terry Reedy

unread,
Jul 27, 2008, 2:18:56 AM7/27/08
to pytho...@python.org

Colin J. Williams wrote:
> Russ P. wrote:

>> class MyClass:
>>
>> def func( , xxx, yyy):
>>
>> .xxx = xxx
>>
>> local = .yyy

The use of <nothing>'.' has been suggested before and rejected.

Terry Reedy

unread,
Jul 27, 2008, 2:20:30 AM7/27/08
to pytho...@python.org

Torsten Bronger wrote:

> No more than Python 3.0 breaks.

This proposal would break 3.0 code without sufficient reason.

Russ P.

unread,
Jul 27, 2008, 2:26:28 AM7/27/08
to

Where and why?

Terry Reedy

unread,
Jul 27, 2008, 2:22:17 AM7/27/08
to pytho...@python.org

Russ P. wrote:
> On Jul 26, 2:25 pm, Terry Reedy
>> There is a lot of code you have not seen. Really. In informal code I
>> use 's' and 'o' for 'self' and 'other'. I don't usually post such
>> because it is not considered polite. So you have seen a biased sample
>> of the universe.
>
> You take the name down to a single letter. As I suggested in an
> earlier post on this thread, why not take it down to zero letters?

Because 1 letter is legal now, while no letters (already proposed and
rejected) is a major change and breakage of current simplicity and
consistency for zero functional benefit.

It is loading more messages.
0 new messages