Guido's new method definition idea

[Hendrik van Rooyen]

Consider the maverick who insists on

8<--------example with "me" instead of "self" --------

What's the interpreter going to do with our maverick's code?

Took me a while, but after I remembered that a "maverick"
is an unmarked, wild member of the bovine species that
is effectively res nullius, I suppose the answer should be that
he or she be brought back into the fold by being branded in
the normal fashion - the application of a hot iron, in the shape
of the standard python logo, to the buttocks.

- Hendrik

 

[Daniel Fetchinson]

Hi folks,

The story of the explicit self in method definitions has been
discussed to death and we all know it will stay. However, Guido
himself acknowledged that an alternative syntax makes perfect sense
and having both (old and new) in a future version of python is a
possibility since it maintains backward compatibility. The alternative
syntax will be syntactic sugar for the old one. This blog post of his
is what I'm talking about:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

The proposal is to allow this:

class C:
def self.method( arg ):
self.value = arg
return self.value

instead of this:

class C:
def method( self, arg ):
self.value = arg
return self.value

I.e. explicit self stays only the syntax is slightly different and may
seem attractive to some. As pointed out by Guido classmethods would
work similarly:

class C:
@classmethod
def cls.method( arg ):
cls.val = arg
return cls.val

The fact that Guido says,

"Now, I'm not saying that I like this better than the status quo. But
I like it a lot better than [...] but it has the great advantage that
it is backward compatible, and can be evolved into a PEP with a
reference implementation without too much effort."

shows that the proposal is viable.

I'd like this new way of defining methods, what do you guys think?
Anyone ready for writing a PEP?

Cheers,
Daniel

 

[James Stroud]

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

The proposal is to allow this:

class C:
def self.method( arg ):
self.value = arg
return self.value

instead of this:

class C:
def method( self, arg ):
self.value = arg
return self.value

I'd like this new way of defining methods, what do you guys think?

Consider the maverick who insists on

class C:
def me.method(arg):
self.value = arg

which should be equivalent to

class C:
def method(me, arg):
me.value = arg

What's the interpreter going to do with our maverick's code?

James

 

[James Stroud]

Of course I meant

class C:
def me.method(arg):
me.value = arg

James

 

[Steven D'Aprano]

Consider the maverick who insists on

class C:
def me.method(arg):
self.value = arg

Replace "self" with "me".

which should be equivalent to

class C:
def method(me, arg):
me.value = arg

What's the interpreter going to do with our maverick's code?

I don't see why you think this is a problem. The compiler merely treats:

def ANYTHING.method(arg):

inside a class as if it were

def method(ANYTHING, arg):


and it will Just Work. If you want a classmethod, you still need to use
the classmethod decorator -- there's no reason to make self and cls
keywords.

Personally, I'm neutral on the idea. Perhaps +0.00001.

 

[Patrick Mullen]

I don't really like the proposed syntax any better than the old
syntax. I certainly wouldn't use "def self." in any of my old code.
I doubt I would use it in a new project were I to have the choice
either. However, I don't really have a problem with other people
liking it.

the symetry of "def self.func(blah)==def func(self,blah)" and
"ob.func(blah)==func(ob.blah)" is kind of neat.

Could I do something like this:

def a.add(b): return a+b

Outside of a class? Of course then that makes you think you could do
5.add(6) or something craaaazy like that. (I mean, you can do
(5).__add__(6) but that's something else entirely)

 

[Kay Schluehr]

Hi folks,

The story of the explicit self in method definitions has been
discussed to death and we all know it will stay. However, Guido
himself acknowledged that an alternative syntax makes perfect sense
and having both (old and new) in a future version of python is a
possibility since it maintains backward compatibility. The alternative
syntax will be syntactic sugar for the old one. This blog post of his
is what I'm talking about:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay...

The proposal is to allow this:

class C:
def self.method( arg ):
self.value = arg
return self.value

instead of this:

class C:
def method( self, arg ):
self.value = arg
return self.value

I.e. explicit self stays only the syntax is slightly different and may
seem attractive to some. As pointed out by Guido classmethods would
work similarly:

class C:
@classmethod
def cls.method( arg ):
cls.val = arg
return cls.val

The fact that Guido says,

"Now, I'm not saying that I like this better than the status quo. But
I like it a lot better than [...] but it has the great advantage that
it is backward compatible, and can be evolved into a PEP with a
reference implementation without too much effort."

shows that the proposal is viable.

So both forms are dual to each other ( "backwards compatibility" ) and
can be used both?

I'm -0 on this although I think the proposition fits better with the
method call syntax.

 

[Russ P.]

Hi folks,

The story of the explicit self in method definitions has been
discussed to death and we all know it will stay. However, Guido
himself acknowledged that an alternative syntax makes perfect sense
and having both (old and new) in a future version of python is a
possibility since it maintains backward compatibility. The alternative
syntax will be syntactic sugar for the old one. This blog post of his
is what I'm talking about:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay...

The proposal is to allow this:

class C:
    def self.method( arg ):
        self.value = arg
        return self.value

instead of this:

class C:
    def method( self, arg ):
        self.value = arg
        return self.value

I.e. explicit self stays only the syntax is slightly different and may
seem attractive to some. As pointed out by Guido classmethods would
work similarly:

class C:
    @classmethod
    def cls.method( arg ):
        cls.val = arg
        return cls.val

The fact that Guido says,

"Now, I'm not saying that I like this better than the status quo. But
I like it a lot better than [...] but it has the great advantage that
it is backward compatible, and can be evolved into a PEP with a
reference implementation without too much effort."

shows that the proposal is viable.

I'd like this new way of defining methods, what do you guys think?
Anyone ready for writing a PEP?

Cheers,
Daniel

I like it.

I'll even go a step further and suggest that "$" be allowed as a
substitute for "self". It looks like a capital "S" (for Self), and it
stands out clearly. It also makes code more succinct with no loss of
readability. Think of the line wraps that could be avoided.

 

[James Stroud]

Consider the maverick who insists on

class C:
def me.method(arg):
self.value = arg

Replace "self" with "me".[/QUOTE]

Yes, I corrected myself one minute after I made the typo.

I don't see why you think this is a problem.

The behavior was unspecified as far as I could tell and I was curious as
to whether "me" would still be allowed as a reference to self. Allowing
alternatives to "self" would maintain backwards compatibility as the use
of self has been a convention and not enforced by the language.

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com

 

[Antoine De Groote]

try this:

and look at the 15th line...

I agree that for newcomers to Python, the class method definition might
seem strange. I certainly had problems with it when starting with
Python, coming from Java. But in the meantime it feels right. I don't
know if it is because I'm used to the old way, but I find the proposed
alternative way slightly less readable.

Altough these are no technical considerations, I'm -1 on this.

Hi folks,

The story of the explicit self in method definitions has been
discussed to death and we all know it will stay. However, Guido
himself acknowledged that an alternative syntax makes perfect sense
and having both (old and new) in a future version of python is a
possibility since it maintains backward compatibility. The alternative
syntax will be syntactic sugar for the old one. This blog post of his
is what I'm talking about:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

The proposal is to allow this:

class C:
def self.method( arg ):
self.value = arg
return self.value

instead of this:

class C:
def method( self, arg ):
self.value = arg
return self.value

I.e. explicit self stays only the syntax is slightly different and may
seem attractive to some. As pointed out by Guido classmethods would
work similarly:

class C:
@classmethod
def cls.method( arg ):
cls.val = arg
return cls.val

The fact that Guido says,

"Now, I'm not saying that I like this better than the status quo. But
I like it a lot better than [...] but it has the great advantage that
it is backward compatible, and can be evolved into a PEP with a
reference implementation without too much effort."

shows that the proposal is viable.

I'd like this new way of defining methods, what do you guys think?
Anyone ready for writing a PEP?

Cheers,
Daniel

 

[Antoine De Groote]

Allowing "$" as a substitute for "self" wouldn't require this new syntax.

class C:
def method($, arg):
$.value = arg

I'm strongly against this. This looks ugly and reminds me of Perl and
Ruby. (I don't have anything against these languages, but there's a
reason I use Python).

Hi folks,

The story of the explicit self in method definitions has been
discussed to death and we all know it will stay. However, Guido
himself acknowledged that an alternative syntax makes perfect sense
and having both (old and new) in a future version of python is a
possibility since it maintains backward compatibility. The alternative
syntax will be syntactic sugar for the old one. This blog post of his
is what I'm talking about:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay...

The proposal is to allow this:

class C:
def self.method( arg ):
self.value = arg
return self.value

instead of this:

class C:
def method( self, arg ):
self.value = arg
return self.value

I.e. explicit self stays only the syntax is slightly different and may
seem attractive to some. As pointed out by Guido classmethods would
work similarly:

class C:
@classmethod
def cls.method( arg ):
cls.val = arg
return cls.val

The fact that Guido says,

"Now, I'm not saying that I like this better than the status quo. But
I like it a lot better than [...] but it has the great advantage that
it is backward compatible, and can be evolved into a PEP with a
reference implementation without too much effort."

shows that the proposal is viable.

I'd like this new way of defining methods, what do you guys think?
Anyone ready for writing a PEP?

Cheers,
Daniel

I like it.

I'll even go a step further and suggest that "$" be allowed as a
substitute for "self". It looks like a capital "S" (for Self), and it
stands out clearly. It also makes code more succinct with no loss of
readability. Think of the line wraps that could be avoided.

 

[Marc 'BlackJack' Rintsch]

try this:


and look at the 15th line...

The reason why I'm against that change too. It adds a second,
alternative way to express something that is already in the language.

I agree that for newcomers to Python, the class method definition might
seem strange.

And after the change it continues to because they will run into *both*
variants in tutorials, code, and books, so it might be even more
confusing.

Ciao,
Marc 'BlackJack' Rintsch

 

[Andreas Waldenburger]

On Sat, 06 Dec 2008 09:56:12 +0100, Antoine De Groote wrote:

[snip reference to "preferably only one way to do it"]

The reason why I'm against that change too. It adds a second,
alternative way to express something that is already in the language.

I agree that for newcomers to Python, the class method definition
might seem strange.

And after the change it continues to because they will run into
*both* variants in tutorials, code, and books, so it might be even
more confusing.

I agree with that view. Not much to add to it, just increasing the
weight.

/W

 

[bearophileHUGS]

Antoine De Groote:

Allowing "$" as a substitute for "self" wouldn't require this new syntax.
class C:
def method($, arg):
$.value = arg

I think this (that is just sugar) may be a little better:

class C:
def method($, arg):
$value = arg

Or even this, combined with the idea suggested in the post by Guido:

class C:
def $method(arg):
$value = arg

(Note there's no point after $, it's not currently possible).
Ruby uses @ and @@ for similar purposes.
I agree that the code looks worse, but also shorter to read and write,
so in lines of code that use many instance attributes, that short $
syntax helps keep the line shorter. So I may grow to accept this
sugar...

Bye,
bearophile

 

[Aaron Brady]

Hi folks,

The story of the explicit self in method definitions has been
discussed to death and we all know it will stay. However, Guido
himself acknowledged that an alternative syntax makes perfect sense
and having both (old and new) in a future version of python is a
possibility since it maintains backward compatibility. The alternative
syntax will be syntactic sugar for the old one. This blog post of his
is what I'm talking about:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay...

The proposal is to allow this:

class C:
    def self.method( arg ):
        self.value = arg
        return self.value

instead of this:

class C:
    def method( self, arg ):
        self.value = arg
        return self.value

I.e. explicit self stays only the syntax is slightly different and may
seem attractive to some.

....

Would it be valid outside class definitions too? (As follows...)

def sequence.shuffle( ):
x= sequence[ 0 ]
sequence[ 0 ]= sequence[ -1 ]
...etc.

shuffle( listA )

Can you still call it by class membership? (As follows...)

C.method( inst, arg )

 

[Andreas Waldenburger]

class C:
def $method(arg):
$value = arg

(Note there's no point after $, it's not currently possible).
Ruby uses @ and @@ for similar purposes.
I agree that the code looks worse, but also shorter to read and write,
so in lines of code that use many instance attributes, that short $
syntax helps keep the line shorter. So I may grow to accept this
sugar...

But that is not the way Python is meant to work. There are several
tennets in the Zen of Python that don't chime well with this approach.
"self" is a speaking identifier, "$" isn't.

we've-been-through-this-ingly yours
/W

 

[Andreas Waldenburger]

class C:
def $method(arg):
$value = arg

[snip]

[snip]
"self" is a speaking identifier, "$" isn't.

Also, nothing prevents you from replacing "self" with "s" if you really
want it short. Same effect as your "s" suggestion (OK, plus one ".").

/W

 

[Antoine De Groote]

Antoine De Groote:

I think this (that is just sugar) may be a little better:

class C:
def method($, arg):
$value = arg

Well, in this case there would be no need to have the $ in the arguments
list, as it would be like a "keyword", or a keysymbol in this case, like
the "this" keyword in Java for instance.
I dislike this even more than the dotted version.

 

[Antoine De Groote]

Hi folks,

The story of the explicit self in method definitions has been
discussed to death and we all know it will stay. However, Guido
himself acknowledged that an alternative syntax makes perfect sense
and having both (old and new) in a future version of python is a
possibility since it maintains backward compatibility. The alternative
syntax will be syntactic sugar for the old one. This blog post of his
is what I'm talking about:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay...

The proposal is to allow this:

class C:
def self.method( arg ):
self.value = arg
return self.value

instead of this:

class C:
def method( self, arg ):
self.value = arg
return self.value

I.e. explicit self stays only the syntax is slightly different and may
seem attractive to some.

...

Would it be valid outside class definitions too? (As follows...)

def sequence.shuffle( ):
x= sequence[ 0 ]
sequence[ 0 ]= sequence[ -1 ]
...etc.

shuffle( listA )

This is not what was intended. The discussion was explicitly only about
class methods.
What you are describing is weird and not generalizable. What if your
method takes more than one parameter? You might argue that "sequence"
would be the first argument in the list, like

def sequence.shuffle(a, b):
"""
a, b: dummy arguments, just for the sake of the example
"""
x = sequence[0]
sequence[0] = sequence[-1
...etc.

shuffle(listA, 1, 1)

I can't think of any good reason to do this. What's more, the whole
discussion was partly due to error messages like

Traceback (most recent call last):
File "classes.py", line 9, in
obj.m2(1)
TypeError: m2() takes exactly 3 arguments (2 given)

Your proposition (well actually it is only a question) would result in
error messages exactly like this one when one would not carefully read
the method signature for example.

Can you still call it by class membership? (As follows...)

C.method( inst, arg )

That should not change at all, as the alternative syntax would actually
be only syntactic sugar.

 

[Colin J. Williams]

Hi folks,

The story of the explicit self in method definitions has been
discussed to death and we all know it will stay. However, Guido
himself acknowledged that an alternative syntax makes perfect sense
and having both (old and new) in a future version of python is a
possibility since it maintains backward compatibility. The alternative
syntax will be syntactic sugar for the old one. This blog post of his
is what I'm talking about:

http://neopythonic.blogspot.com/2008/10/why-explicit-self-has-to-stay.html

The proposal is to allow this:

class C:
def self.method( arg ):
self.value = arg
return self.value

instead of this:

class C:
def method( self, arg ):
self.value = arg
return self.value

I.e. explicit self stays only the syntax is slightly different and may
seem attractive to some. As pointed out by Guido classmethods would
work similarly:

class C:
@classmethod
def cls.method( arg ):
cls.val = arg
return cls.val

The fact that Guido says,

"Now, I'm not saying that I like this better than the status quo. But
I like it a lot better than [...] but it has the great advantage that
it is backward compatible, and can be evolved into a PEP with a
reference implementation without too much effort."

shows that the proposal is viable.

I'd like this new way of defining methods, what do you guys think?
Anyone ready for writing a PEP?

Cheers,
Daniel

The quoted blogspot is not available.

I like the idea but I don't see how
explicit and implicit can co-exist.

Version 3.0 is the time to introduce the
enhancement.

Colin W.