Attack a sacred Python Cow

[Terry Reedy]

Re: Attack a sacred Python Cow



Nikolaus Rath wrote:

Terry Reedy <tjreedy@udel.e duwrites:

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

Re: Attack a sacred Python Cow

On Jul 24, 6:41 am, Jordan <jordanrastr... @gmail.comwrote :

Hi everyone,
>
I'm a big Python fan who used to be involved semi regularly in
comp.lang.pytho n (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]

Re: Attack a sacred Python Cow

On 25 Jul, 22:37, Terry Reedy <tjre...@udel.e duwrote:

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]

Re: Attack a sacred Python Cow

Fuzzyman wrote:

On Jul 24, 6:41 am, Jordan <jordanrastr... @gmail.comwrote :

>Hi everyone,
>>
>I'm a big Python fan who used to be involved semi regularly in
>comp.lang.pyth on (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/

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]

Re: Attack a sacred Python Cow

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 misunderstandin g 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]

Re: Attack a sacred Python Cow



Paul Boddie wrote:

On 25 Jul, 22:37, Terry Reedy <tjre...@udel.e duwrote:

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

Re: Attack a sacred Python Cow

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 misunderstandin g 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

[Torsten Bronger]

Re: Attack a sacred Python Cow

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: torsten.bronger @jabber.rwth-aachen.de

[Carl Banks]

Re: Attack a sacred Python Cow

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

[Carl Banks]

Re: Attack a sacred Python Cow

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 "Readabilit y 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

[Nikolaus Rath]

Re: Attack a sacred Python Cow

Terry Reedy <tjreedy@udel.e duwrites:

Nikolaus Rath wrote:

>Terry Reedy <tjreedy@udel.e duwrites:

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

[Steven D'Aprano]

Re: Attack a sacred Python Cow

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

Terry Reedy <tjreedy@udel.e duwrites:

....

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

Re: Attack a sacred Python Cow

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:874p6fzkk h.fsf@physik.rw th-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: torsten.bronger @jabber.rwth-aachen.de

[D'Arcy J.M. Cain]

Re: Attack a sacred Python Cow

On Sat, 26 Jul 2008 09:45:21 +0200
Torsten Bronger <bronger@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 <darcy@druid.ne t | 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]

Re: Attack a sacred Python Cow

Hallöchen!

D'Arcy J.M. Cain writes:

On Sat, 26 Jul 2008 09:45:21 +0200
Torsten Bronger <bronger@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: torsten.bronger @jabber.rwth-aachen.de