473,287 Members | 1,793 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,287 software developers and data experts.

Attack a sacred Python Cow

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.
Jul 24 '08
270 7832


Paul Boddie wrote:
On 25 Jul, 22:37, Terry Reedy <tjre...@udel.eduwrote:
>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

Jul 26 '08 #51
Jordan wrote:
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 :-)
--
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
Jul 26 '08 #52
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)". ;-)

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: to*************@jabber.rwth-aachen.de
Jul 26 '08 #53
On Jul 24, 4:11*am, Jordan <jordanrastr...@gmail.comwrote:
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
Jul 26 '08 #54
On Jul 24, 1:41*am, Jordan <jordanrastr...@gmail.comwrote:
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
Jul 26 '08 #55
Terry Reedy <tj*****@udel.eduwrites:
Nikolaus Rath wrote:
>Terry Reedy <tj*****@udel.eduwrites:
>>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.

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.

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

Jul 26 '08 #56
On Sat, 26 Jul 2008 11:08:12 +0200, Nikolaus Rath wrote:
Terry Reedy <tj*****@udel.eduwrites:
....
>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
Jul 26 '08 #57
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:87************@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.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: to*************@jabber.rwth-aachen.de
Jul 26 '08 #58
On Sat, 26 Jul 2008 09:45:21 +0200
Torsten Bronger <br*****@physik.rwth-aachen.dewrote:
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.
Jul 26 '08 #59
Hallöchen!

D'Arcy J.M. Cain writes:
On Sat, 26 Jul 2008 09:45:21 +0200
Torsten Bronger <br*****@physik.rwth-aachen.dewrote:
>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.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: to*************@jabber.rwth-aachen.de
Jul 26 '08 #60
On Sat, 26 Jul 2008 16:25:18 +0200
Torsten Bronger <br*****@physik.rwth-aachen.dewrote:
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." :-)

--
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.
Jul 26 '08 #61
Hallöchen!

D'Arcy J.M. Cain writes:
On Sat, 26 Jul 2008 16:25:18 +0200
Torsten Bronger <br*****@physik.rwth-aachen.dewrote:
>>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:87************@physik.rwth-aachen.de). I just don't think
that some popular counter-arguments are compelling. ;-)

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: to*************@jabber.rwth-aachen.de
Jul 26 '08 #62
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?
Jul 26 '08 #63
Hallöchen!

Kay Schluehr writes:
On 26 Jul., 09:45, Torsten Bronger <bron...@physik.rwth-aachen.de>
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.

??

This is an extra requirement. Why do you want to make 'self' a
keyword?
How could one determine which other identifier must be inserted into
the method's signature?

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: to*************@jabber.rwth-aachen.de
Jul 26 '08 #64
In article <58**********************************@q28g2000prh. googlegroups.com>,
Jordan <jo************@gmail.comwrote:
>
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!
Jul 26 '08 #65
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
Jul 26 '08 #66
On 26 Jul, 06:06, Terry Reedy <tjre...@udel.eduwrote:
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
Jul 26 '08 #67


Carl Banks wrote:
On Jul 24, 4:11 am, Jordan <jordanrastr...@gmail.comwrote:
>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".
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

Jul 26 '08 #68


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?

Jul 26 '08 #69


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

Jul 26 '08 #70


Torsten Bronger wrote:
Hallöchen!

D'Arcy J.M. Cain writes:
>On Sat, 26 Jul 2008 09:45:21 +0200
Torsten Bronger <br*****@physik.rwth-aachen.dewrote:
>>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.

Jul 26 '08 #71
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.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: to*************@jabber.rwth-aachen.de
Jul 26 '08 #72


Paul Boddie wrote:
On 26 Jul, 06:06, Terry Reedy <tjre...@udel.eduwrote:
>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

Jul 26 '08 #73
Hallöchen!

Terry Reedy writes:
Torsten Bronger wrote:
>D'Arcy J.M. Cain writes:
>>On Sat, 26 Jul 2008 09:45:21 +0200
Torsten Bronger <br*****@physik.rwth-aachen.dewrote:

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.
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.

Tschö,
Torsten.

--
Torsten Bronger, aquisgrana, europa vetus
Jabber ID: to*************@jabber.rwth-aachen.de
Jul 26 '08 #74
On Jul 26, 5:07*pm, Terry Reedy <tjre...@udel.eduwrote:
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
Jul 26 '08 #75
In message
<02**********************************@v1g2000pra.g ooglegroups.com>,
s0****@gmail.com wrote:
On Jul 24, 5:01 am, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealandwrote:
>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".
Jul 26 '08 #76
In message
<43**********************************@k36g2000pri. googlegroups.com>,
s0****@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.
Jul 26 '08 #77
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):

Jul 27 '08 #78
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

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? 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):

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


Jul 27 '08 #79
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.

Jul 27 '08 #80
On Jul 26, 6:47 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealandwrote:
In message
<024ace13-f72f-4093-bcc9-f8a339c32...@v1g2000pra.googlegroups.com>,

s0s...@gmail.com wrote:
On Jul 24, 5:01 am, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealandwrote:
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".
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.)

Jul 27 '08 #81


Torsten Bronger wrote:
No more than Python 3.0 breaks.
This proposal would break 3.0 code without sufficient reason.

Jul 27 '08 #82


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.

Jul 27 '08 #83
On Jul 26, 11:22 pm, Terry Reedy <tjre...@udel.eduwrote:
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.
Sorry, but I fail to see how it is a "major change." It only applies
to the first argument of a class member function, and the parser only
needs to look for an empty argument or a period. Furthermore, it would
break no working code.

It may indeed have been "proposed and rejected," but it would be a
nice way to clean up code in many areas, and as long as it cannot
break any working code, I think it should be reconsidered.
Jul 27 '08 #84
On 26 Jul., 19:20, Michele Simionato <michele.simion...@gmail.com>
wrote:
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
Incidentally I knew that I had to overload the negation of __eq__
explicitely and did so writing
an __neq__ method. A few minutes later I found out it's not __neq__
but __ne__. So another few minutes were lost.
Jul 27 '08 #85
Terry Reedy <tj*****@udel.eduwrites:
>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.
Well, I guess that's more a matter of personal preference. I would go
for it immediately (and also try rename it to '@' at the same time).
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

Jul 27 '08 #86
On Sun, 27 Jul 2008 10:23:06 +0800, Marcus.CM wrote:
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.
You know, there are some programmers who haven't started with C++ or Java.

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.
Would I?

How would I do that here?

# untested
class FunnyNumber(int):
"""Silly class that acts like an integer, only one larger."""
def __add__(self, other):
return int(self)+1+other
def __mul__(self, other):
return (self+1)*other
def __sub__(self, other):
return int(self)+1-other

--
Steven
Jul 27 '08 #87
On Sat, 26 Jul 2008 17:14:46 -0700, 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?
The question isn't "why not", but "why". The status quo works well as it
is, even if it isn't perfect. Prove that implicit self is a good idea --
or at least prove that it is an idea worth considering.

"I don't like typing self" doesn't convince me. The same argument could
be made typing parentheses, colons, commas, etc. We could end up with
something like this:

class Foo base
def method x y z
.args = list x y z
That's not necessarily wrong, but it's not Python.

It's not enough to show that a change "isn't bad" -- you have to show
that it is actively good. Why should Python make any changes to the
current explicit self without a clear and solid reason to change?
You could if Python accepted something like

class Whatever:

def fun( , cat):

.cat = cat

This is even better than the single-character name,
By "better" do you mean "uglier"? If so, I agree with you. If not, then I
disagree that it is better.

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.
"Don't need to look at the method signature" is not an argument in favour
of implicit self. You don't need to look at the method signature when
you're using an explicit self either.

What happens with class-methods? With the cls (or if you prefer klass)
convention, it is simple to tell what object I am referring to. Now I
have to go back to the method signature to see if it is a class method or
instance method, instead of just looking at the explicit name.
For those who don't like the way the empty first argument looks, maybe
something like this could be allowed:

def fun( ., cat):

Even uglier than the first. Convince me there's a benefit.

--
Steven
Jul 27 '08 #88
On Sat, 26 Jul 2008 15:58:16 -0700, Carl Banks wrote:
On Jul 26, 5:07Â*pm, Terry Reedy <tjre...@udel.eduwrote:
>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.
But why do you need the explicit test? What benefit do you get from

if len(alist) != 0

instead of the simpler and faster "if alist" ? If you need to know that
alist is actually a list, isinstance() is the function you want; and if
you want to know that it has a length, hasattr(alist, '__len__') is
better. (Or call len() in a try...except block.) Either way, testing the
length is zero explicitly gains you nothing, and risks failure for any
sequence types that might distinguish between an empty sequence and a
length of zero.

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.
You might find it pretty weak, but I find it a wonderful, powerful
feature.

I recently wrote a method that sequentially calls one function after
another with the same argument, looking for the first function that
claims a match by returning a non-false result. It looked something like
this:

def match(arg, *functions):
for func in functions:
if func(arg):
return func

I wanted the function itself, not the result of calling the function. I
didn't care what the result was, only that it was something (indicates a
match) or nothing (no match). In one application, the functions might
return integers or floats; in another they might return strings. In a
third, they might return re match objects or None. I don't need to care,
because my code doesn't make any assumptions about the type of the result.
--
Steven
Jul 27 '08 #89
On Jul 27, 4:26*pm, "Russ P." <Russ.Paie...@gmail.comwrote:
On Jul 26, 11:18 pm, Terry Reedy <tjre...@udel.eduwrote:
The use of <nothing>'.' has been suggested before and rejected.

Where and why?
Google is your friend:
http://mail.python.org/pipermail/pyt...il/000793.html
Jul 27 '08 #90
On Sat, 26 Jul 2008 21:46:31 -0700, s0suk3 wrote:
(It's true that C++ has more OO features than Python, like private/
public members, virtual methods, etc.
Oh yeah, again the discussion about `private`/`public` and if that's an
important OOP feature. :-)

Aren't *all* methods in Python "virtual"?

And what's "etc."?

Ciao,
Marc 'BlackJack' Rintsch
Jul 27 '08 #91


Steven D'Aprano wrote:
On Sun, 27 Jul 2008 10:23:06 +0800, Marcus.CM wrote:
>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.

You know, there are some programmers who haven't started with C++ or Java.
Like my teenager, who is only 1 of many kids learning Python as a first
algorithm language. If not now, eventually, I expect a majority of
Python programmers to *not* be C++/Java graduates.

tjr

Jul 27 '08 #92
On Jul 27, 2:56*am, Nikolaus Rath <Nikol...@rath.orgwrote:
Terry Reedy <tjre...@udel.eduwrites:
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.

Well, I guess that's more a matter of personal preference. I would go
for it immediately (and also try rename it to '@' at the same time).

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
Hardy has an interesting claim. OT.

He has omitted a couple of lemmas, which aren't true.

1: There are enough people to be in the majority.
2: It is not worthwhile to be in the majority.
3: There is no majority of worthwhile timespending.
4: There is no majority of intelligent men.
5: Being in the majority takes time.

It is worth some intelligent men's time to be in the majority; the
majority of intelligent men are intelligent men, and are in the
majority of intelligent men. Perhaps it is merely not worth their
time to be.
Jul 27 '08 #93
On Jul 26, 4:08*am, Nikolaus Rath <Nikol...@rath.orgwrote:
Terry Reedy <tjre...@udel.eduwrites:
Nikolaus Rath wrote:
Terry Reedy <tjre...@udel.eduwrites:
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.

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.

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
There's a further advantage:

class A:
def get_auxclass( self, b, c ):
class B:
def auxmeth( self2, d, e ):
#here, ...
return B

Because Python permits you to name 'the current instance' any name you
want, you're able to hold more than one current instance at one time.
In this case, you could write 'return self.val+ self2.val' with no
trouble, while I'm not even sure that anything like that is possible
in C, C++, Java, or anything higher other than Python. (This is a
good point, outside of the usual, by the way.)
Jul 27 '08 #94
On Jul 27, 3:11 am, alex23 <wuwe...@gmail.comwrote:
On Jul 27, 4:26 pm, "Russ P." <Russ.Paie...@gmail.comwrote:
On Jul 26, 11:18 pm, Terry Reedy <tjre...@udel.eduwrote:
The use of <nothing>'.' has been suggested before and rejected.
Where and why?

Google is your friend:http://mail.python.org/pipermail/pyt...il/000793.html
What Guido rejected there is most certainly *not*
what I suggested. I agree with Guido on that one.
Jul 27 '08 #95
On Sat, Jul 26, 2008 at 12:06:05AM -0400, Terry Reedy wrote:
There is no requirement to have 'self' in the parameter list.
But there is a requirement to have *something* which refers to the
object instance. Why can't this be implicit with a keyword defined in
python to refer to it?
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.
That's crazy talk.
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'
s = self

There, your problem is fixed. Besides, in general, it's better
programming practie to use meaningful names, with fairly obvious and
well-understood exceptions.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIjMaMdjdlQoHP510RAi9AAJ9byGW+Z8SpcpsOTa5/Gxv1Q0p4RQCeI9r9
RxR6az2XlvRV2lqulhW992g=
=SX6e
-----END PGP SIGNATURE-----

Jul 27 '08 #96
On Jul 27, 1:19 am, Steven D'Aprano <st...@REMOVE-THIS-
cybersource.com.auwrote:
On Sat, 26 Jul 2008 17:14:46 -0700, Russ P. wrote:
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?

The question isn't "why not", but "why". The status quo works well as it
is, even if it isn't perfect. Prove that implicit self is a good idea --
or at least prove that it is an idea worth considering.

"I don't like typing self" doesn't convince me. The same argument could
be made typing parentheses, colons, commas, etc. We could end up with
something like this:

class Foo base
def method x y z
.args = list x y z

That's not necessarily wrong, but it's not Python.
And what does that have to do with my suggestion? Absolutely nothing.
It's a red herring that you seem to be using to obscure the fact that
you have no rational argument to make.

By the way, according to your "reasoning," Python 2.5 was *not* Python
when 2.1 was the latest version. But now it is! Yes, Python has
actually changed, yet remained Python. What a concept!
It's not enough to show that a change "isn't bad" -- you have to show
that it is actively good. Why should Python make any changes to the
current explicit self without a clear and solid reason to change?
You could if Python accepted something like
class Whatever:
def fun( , cat):
.cat = cat
This is even better than the single-character name,

By "better" do you mean "uglier"? If so, I agree with you. If not, then I
disagree that it is better.
You seem to be freaked out by an empty argument. Actually, it bothers
me a bit too, which is why I suggested that a period could be used as
the first argument to indicate that, like Clint Eastwood in The Good,
the Bad, and the Ugly, "self" had no name here.
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.

"Don't need to look at the method signature" is not an argument in favour
of implicit self. You don't need to look at the method signature when
you're using an explicit self either.
Actually, you do. The name "self" could be used for any argument -- or
even for a local variable. No good programmer would do such a thing,
of course, but not all programmers are good programmers (and not all
Python programmers read the stern admonitions against such practices
on this forum). And if you are reviewing critical code, you had darn
well better verify that "self" is the first argument. With my
proposal, you would not need to do that.

Is that a major advantage? No. But it is a minor advantage. And it is
perfectly logical.

Am I suggesting that unnamed first arguments should always be used?
No, of course not. But I am saying that in some cases it can unclutter
and simplify the code.
What happens with class-methods? With the cls (or if you prefer klass)
convention, it is simple to tell what object I am referring to. Now I
have to go back to the method signature to see if it is a class method or
instance method, instead of just looking at the explicit name.
Bzzzzt. Wrong again. The exact same convention could apply there. And
the same benefits apply: less clutter and no need to keep the name of
the first argument in your head when reading the code.
For those who don't like the way the empty first argument looks, maybe
something like this could be allowed:
def fun( ., cat):

Even uglier than the first. Convince me there's a benefit.
Actually, I think it's elegant. And I'll bet that if Guido had
suggested it, you would think it was beautiful. Why force a name to be
used when none is needed? Think about lambda functions.
Jul 27 '08 #97
On Sun, Jul 27, 2008 at 08:13:53AM +0000, Steven D'Aprano wrote:
On Sun, 27 Jul 2008 10:23:06 +0800, Marcus.CM wrote:
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.

You know, there are some programmers who haven't started with C++ or Java.
Indeed, I'm one of them. In fact, I've never written even a single
program in either language (except maybe hello world or the
equivalent), and still, I have always thought that explicitly naming
the class instance variable in the parameter list of the object's
methods was a wart (albeit a very minor one) in Python. It's a waste
of typing.
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.

Would I? How would I do that here?
You missed the point. The variable "other" in your posted class is
not intended to always refer to the same *object*... Whereas "self"
is and does, and that was what was meant. In such a case, you'd
obviously convert the variable to a class property.

Regardless of how it's implementd, it's such a common idiom to use
self to refer to object instances within a class in Python that it
ought to be more automatic. Personally, I kind of like the idea of
using @ and thinking of it more like an operator... Kind of like
dereferencing a pointer, only with an implied pointer name.

class foo:
def __init__():
@.increment = 2

def bar(a)
return a + @.increment

I'm sure all the Pythonistas will hate this idea though... ;-) To be
honest, it smacks a little of Perl's magic variables, which I actually
hate with a passion. This is the only place in Python I'd consider
doing something like this.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIjM24djdlQoHP510RAjTtAJ4wLwVPBnLacpyZ7k/++534A/RlQwCgkkFe
bcd7NfxqgBAdIrbTYKLOeBs=
=mYoU
-----END PGP SIGNATURE-----

Jul 27 '08 #98
On Sun, Jul 27, 2008 at 08:19:17AM +0000, Steven D'Aprano wrote:
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?

The question isn't "why not", but "why". The status quo works well as it
is, even if it isn't perfect. Prove that implicit self is a good idea --
or at least prove that it is an idea worth considering.
Come on, this sounds like a schoolyard argument. This comes down to a
matter of style, and as such, is impossible to prove. It's largely a
question of individual preference.

That said, the argument in favor is rather simple:

1. This is an extremely common idiom in Python
2. It is completely unnecessary, and the language does not suffer for
making it implicit
3. Making it implicit reduces typing, reduces opportunities for
mistakes, and arguably increases consistency.

As for the latter part of #3, self (or some other variable) is
required in the parameter list of object methods, however when the
method is *called*, it is omitted. It is implied, supplied by Python.
Thus when an object method is called, it must be called with one fewer
arguments than those which are defined. This can be confusing,
especially to new programmers.

It can also be argued that it makes the code less ugly, though again,
that's a matter of preference.
It's not enough to show that a change "isn't bad" -- you have to show
that it is actively good.
But he did... he pointed out that *it saves work*, without actually
being bad. Benefit, without drawback. Sounds good to me!
"Don't need to look at the method signature" is not an argument in favour
of implicit self.
Yes, actually, it is. If there is a well-defined feature of Python
which provides access to the object within itself, then the
opportunities for mistakes when someone decides to use something else
are lessened.
You don't need to look at the method signature when you're using an
explicit self either.
That isn't necessarily true. If you're using someone else's code, and
they didn't use "self" -- or worse yet, if they chose this variable's
name randomly throughout their classes -- then you may well need to
look back to see what was used.

It's bad programming, but the world is full of bad programmers, and we
don't always have the choice not to use their code. Isn't one of
Python's goals to minimize opportunities for bad programming?
Providing a keyword equivalent to self and removing the need to name
it in object methods is one way to do that.

--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFIjNOedjdlQoHP510RAtotAJ95r36fE916fPj17A4JTv Q3QeDRRQCfdTfl
KHUhu1W4mJv/t81hTZw8LyA=
=Qcfc
-----END PGP SIGNATURE-----

Jul 27 '08 #99

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? 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):
I don't see the need for the comma in fun.

Colin W.
Jul 27 '08 #100

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.