Guido's new method definition idea

Russ P. Russ.Paielli at gmail.com
Sat Dec 6 17:39:34 EST 2008


On Dec 6, 1:21 pm, Carl Banks <pavlovevide... at gmail.com> wrote:
> On Dec 6, 9:12 am, "Russ P." <Russ.Paie... at gmail.com> wrote:
>
>
>
> > On Dec 6, 1:02 am, Antoine De Groote <anto... at vo.lu> wrote:
>
> > > 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).
>
> > > Russ P. wrote:
> > > > On Dec 5, 6:21 pm, "Daniel Fetchinson" <fetchin... at googlemail.com>
> > > > wrote:
> > > >> 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
>
> > > >> --
> > > >> Psss, psss, put it down! -http://www.cafepress.com/putitdown
>
> > > > 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.
>
> > It looks "ugly" simply because it is new to you. Once you get used to
> > it, I'll bet it will look fine. And resemblance to another language is
> > not a very good reason to reject it.
>
> Perl is not new to me and I am familiar with the syntax, such as it
> is.  I find it unspeakably ugly.  So, no, you would lose your bet if
> it were me.
>
> Carl Banks

I don't know much about Perl, but my understanding is that a dollar
sign must be used every time a variable is dereferenced, as in bash or
other shell languages. What we are proposing here is something
entirely different: the dollar sign would simply be a shorthand for
"self". In Perl, the dollar sign is clutter, but in this case it
actually reduces clutter.

Python already uses shorthand extensively. How about "def"? For people
who are so worried about self-explanatory symbols, what the heck does
that stand for? Default? Defeat? Defect? Defunct? Defer?

At some time in the past, a conscious decision was made to save three
characters in the word "define" by abbreviating it as "def". The
suggestion to abbreviate "self" as "$" also saves three characters.
And "self" appears much more often than "def", so an abbreviation is
equally or more justified in my opinion.



More information about the Python-list mailing list