should "self" be changed?

classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

zipher
Would it be prudent to rid the long-standing "argument" (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name?  

Something like:

class MyClass(object):

    def __init__(@):
        @.dummy = None

OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*.

class MyClass(object):

    def __init__(): #takes no arguments!
        @.dummy = None  #the @ invokes the class object's dictionary

That would seem to be a nice solution to the problem, really.  It doesn't become PERLish because you've made it into a genuine operator -- "self" was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched.

Anyone else have any thoughts?

--mark


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Laura Creighton-2
In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes:

>Would it be prudent to rid the long-standing "argument" (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name?  
>
>Something like:
>
>class MyClass(object):
>
>    def __init__(@):
>        @.dummy = None
>
>OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*.
>
>class MyClass(object):
>
>    def __init__(): #takes no arguments!
>        @.dummy = None  #the @ invokes the class object's dictionary
>
>That would seem to be a nice solution to the problem, really.  It doesn't become PERLish because you've made it into a genuine operator -- "self" was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched.
>
>Anyone else have any thoughts?

Guido did.  :)
http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html

Laura


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Laurent Pointal-4
In reply to this post by zipher
zipher wrote:

> Would it be prudent to rid the long-standing "argument" (pun unintended)
> about self and the ulterior spellings of it, by changing it into a symbol
> rather than a name?
>
> Something like:
>
> class MyClass(object):
>
>     def __init__(@):
>         @.dummy = None

Just seeing the Python3.5 announce with @ used as matrix multiplication
operator ;-)

> OR, even better, getting *rid of it* in the parameter list, so it stops
> confusing people about how many parameters a method needs, and transform
> it into a true *operator*.

Self is not an operator, its the target object as first parameter. And with
Python you can call some methods directly using theclass.themethod(objet,
param1, param2).

> class MyClass(object):
>
>     def __init__(): #takes no arguments!
>         @.dummy = None  #the @ invokes the class object's dictionary
>
> That would seem to be a nice solution to the problem, really.  It doesn't
> become PERLish because you've made it into a genuine operator -- "self"
> was always a non-variable that looked like a variable and hence created an
> itch that couldn't be scratched.

?Explicit is better than implicit?

I think that googling for that idea you will find other people already
proposing it (I've seen propositions to directly remove part before the dot
like this: .dummy = None). Just read it.

> Anyone else have any thoughts?

IMHO Zero chance that it be adopted.

A+
Laurent.



Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Mark Lawrence
In reply to this post by zipher
On 26/05/2015 17:37, zipher wrote:

> Would it be prudent to rid the long-standing "argument" (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name?
>
> Something like:
>
> class MyClass(object):
>
>      def __init__(@):
>          @.dummy = None
>
> OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*.
>
> class MyClass(object):
>
>      def __init__(): #takes no arguments!
>          @.dummy = None  #the @ invokes the class object's dictionary
>
> That would seem to be a nice solution to the problem, really.  It doesn't become PERLish because you've made it into a genuine operator -- "self" was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched.
>
> Anyone else have any thoughts?
>
> --mark
>

Yes, how about you taking a permanent holiday rather than bother this
list with more of your nonsense?

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Chris Angelico
On Wed, May 27, 2015 at 3:28 AM, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
> Yes, how about you taking a permanent holiday rather than bother this list
> with more of your nonsense?

No need to be nasty about it. The suggestion is a plausible one, it
just happens to not fit Python's philosophy. The best response is to
quote Guido's statement on the subject... which is exactly what Laura
already did. :)

ChrisA


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

random832@fastmail.us
In reply to this post by Laura Creighton-2
On Tue, May 26, 2015, at 12:57, Laura Creighton wrote:
> Guido did.  :)
> http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html

It's worth noting that the "dynamically modify a class" argument (and to
some extent the decorator argument) misses Javascript's solution - _any_
function may refer to "this" (which is not in the argument list), which
will be the global scope object (the browser window for browser-hosted
javascript - presumably the current module for a hypothetical equivalent
python feature, though it might be more prudent to simply make it None.)
if the function is called without an object reference. Of course,
Javascript also lacks bound methods, which makes it much more likely to
happen by accident.

I can't really think of anything that you can do with decorators,
either, in the current model, that you _couldn't_ do in a JS-alike
function call model... but I doubt it would be possible to implement
backwards-compatibly.

In principle, if you added a class keyword (hey, technically, isn't
there one already?) you wouldn't need decorators at all for the
staticmethod/classmethod/instance method case.


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Marko Rauhamaa
In reply to this post by zipher
zipher <dreamingforward at gmail.com>:

> Would it be prudent to rid the long-standing "argument" (pun
> unintended) about self and the ulterior spellings of it, by changing
> it into a symbol rather than a name?
>
> Something like:
>
> class MyClass(object):
>
>     def __init__(@):
>         @.dummy = None
>
> OR, even better, getting *rid of it* in the parameter list, so it
> stops confusing people about how many parameters a method needs, and
> transform it into a true *operator*.

Python's practice works. However, a small problem is presented by nested
classes:

    class Connection:
        def __init__(self):
            class Idle:
                def signal_start(self):
                    # how to refer to the outer self
                    :
            :

Solutions include:

    class Connection:
        def __init__(self):
            class Idle:
                def signal_start(_):
                    self.set_state(Ready)
            :


    class Connection:
        def __init__(self):
            conn = self
            class Idle:
                def signal_start(self):
                    conn.set_state(Ready)
            :


I have used the latter method recently.


Marko


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Ned Batchelder
On Tuesday, May 26, 2015 at 3:47:20 PM UTC-4, Marko Rauhamaa wrote:

> zipher <dreamingforward at gmail.com>:
>
> > Would it be prudent to rid the long-standing "argument" (pun
> > unintended) about self and the ulterior spellings of it, by changing
> > it into a symbol rather than a name?
> >
> > Something like:
> >
> > class MyClass(object):
> >
> >     def __init__(@):
> >         @.dummy = None
> >
> > OR, even better, getting *rid of it* in the parameter list, so it
> > stops confusing people about how many parameters a method needs, and
> > transform it into a true *operator*.
>
> Python's practice works. However, a small problem is presented by nested
> classes:
>
>     class Connection:
>         def __init__(self):
>             class Idle:
>                 def signal_start(self):
>                     # how to refer to the outer self
>                     :
>             :
>
> Solutions include:
>
> ...
>
>     class Connection:
>         def __init__(self):
>             conn = self
>             class Idle:
>                 def signal_start(self):
>                     conn.set_state(Ready)
>             :
>
>
> I have used the latter method recently.

I would find it much clearer to not use a nested class
at all, and instead to pass the object into the constructor:

    class Idle:
        def __init__(self, conn):
            self.conn = conn
        def signal_start(self):
            self.conn.set_state(Ready)

    class Connection:
        def __init__(self):
            something(Idle(self))

--Ned.


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

garabik-news-2005-05@kassiopeia.juls.savba.sk
In reply to this post by zipher
zipher <dreamingforward at gmail.com> wrote:

> Would it be prudent to rid the long-standing "argument" (pun
> unintended) about self and the ulterior spellings of it, by changing
> it into a symbol rather than a name?  
>
> Something like:
>
> class MyClass(object):
>
>     def __init__(@):
>         @.dummy = None

Believe or not, python3 (via Guido's time machine) already anticipated
this suggestion and you can indeed use a symbol instead of 'self':

class MyClass(object):

   def __init__(?):
       ?.dummy = None

--
 -----------------------------------------------------------
| Radovan Garab?k http://kassiopeia.juls.savba.sk/~garabik/ |
| __..--^^^--..__    garabik @ kassiopeia.juls.savba.sk     |
 -----------------------------------------------------------
Antivirus alert: file .signature infected by signature virus.
Hi! I'm a signature virus! Copy me into your signature file to help me spread!


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Marko Rauhamaa
In reply to this post by Ned Batchelder
Ned Batchelder <ned at nedbatchelder.com>:

> I would find it much clearer to not use a nested class at all, and
> instead to pass the object into the constructor:

Nested classes are excellent and expressing the state pattern <URL:
http://en.wikipedia.org/wiki/State_pattern>.


Marko


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Mark Lawrence
In reply to this post by garabik-news-2005-05@kassiopeia.juls.savba.sk
On 26/05/2015 21:26, garabik-news-2005-05 at kassiopeia.juls.savba.sk wrote:

> zipher <dreamingforward at gmail.com> wrote:
>> Would it be prudent to rid the long-standing "argument" (pun
>> unintended) about self and the ulterior spellings of it, by changing
>> it into a symbol rather than a name?
>>
>> Something like:
>>
>> class MyClass(object):
>>
>>      def __init__(@):
>>          @.dummy = None
>
> Believe or not, python3 (via Guido's time machine) already anticipated
> this suggestion and you can indeed use a symbol instead of 'self':
>
> class MyClass(object):
>
>     def __init__(?):
>         ?.dummy = None
>

Apart from breaking all the tools that rely on "self" being spelt "self"
this looks like an excellent idea.

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence



Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

TIm Chase-3
On 2015-05-26 21:45, Mark Lawrence wrote:
>> class MyClass(object):
>>     def __init__(?):
>>         ?.dummy = None
>
> Apart from breaking all the tools that rely on "self" being spelt
> "self" this looks like an excellent idea.

Though to be fair, they *are* broken tools if they rely on "self"
since there's nothing in the Python specs that require that.  It's
just a convention[1].

-tkc


[1]
https://docs.python.org/2/tutorial/classes.html#random-remarks
"""
Often, the first argument of a method is called self. This is nothing
more than a convention: the name self has absolutely no special
meaning to Python. Note, however, that by not following the
convention your code may be less readable to other Python
programmers, and it is also conceivable that a class browser program
might be written that relies upon such a convention.
"""
It does give fair warning, but I'd consider that a warning to authors
of "class browser program[s]" as much as to developers.





Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Vito De Tullio
In reply to this post by Mark Lawrence
Mark Lawrence wrote:

>>     def __init__(?):
>>         ?.dummy = None

> Apart from breaking all the tools that rely on "self" being spelt "self"
> this looks like an excellent idea.

too bad for the tools: using the name "self" is just a convention, not a
rule.

--
By ZeD



Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

zipher
In reply to this post by zipher
On Tuesday, May 26, 2015 at 12:28:31 PM UTC-5, Mark Lawrence wrote:
> On 26/05/2015 17:37, zipher wrote:
> > Would it be prudent to rid the long-standing "argument" (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name?
>
> Yes, how about you taking a permanent holiday rather than bother this
> list with more of your nonsense?
>
> Mark Lawrence

Mr. Lawrence, could you calm down with your sadism on the list.  Our session last time ended with a lot of semen on your floor instead of in your mouth.

Your bosom buddy,

Mark Janssen


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

zipher
In reply to this post by zipher
On Tuesday, May 26, 2015 at 11:57:44 AM UTC-5, Laura Creighton wrote:
> In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes:
> >Would it be prudent to rid the long-standing "argument" (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name?  

> >class MyClass(object):
> >
> >    def __init__(@):
> >        @.dummy = None
> >
> >OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*.
> >
> >class MyClass(object):
> >
> >    def __init__(): #takes no arguments!
> >        @.dummy = None  #the @ invokes the class object's dictionary
> >
> >That would seem to be a nice solution to the problem, really.  It doesn't become PERLish because you've made it into a genuine operator -- "self" was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched.
>
> Guido did.  :)
> http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html

Sweet link.  I see now that my confusion surrounds the mistaken notion that Python is lexing python source into *abstract syntax trees* (wikipedia describes nicely), so that code inside a method knows what class it's in.

But GvR hasn't defined his language to the extent where the notion of "object" even exists.  He's only set aside a keyword called "class".  So of course he has to treat the method code, practically, like a [C] function.  But that limits the language, not to define what an object is inside the lexical structure:

object ::= "class" identifier "(" inheritence_list ")" ":"
inheritence_list ::= [[et cetera]]

If he did this, then code inside the class could already know what class they're in and all the objections in Laura's link would be moot.

Mark J



Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

zipher
In reply to this post by zipher
On Tuesday, May 26, 2015 at 11:57:44 AM UTC-5, Laura Creighton wrote:

> In a message of Tue, 26 May 2015 09:37:29 -0700, zipher writes:
> >Would it be prudent to rid the long-standing "argument" (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name?  
> >
> >Something like:
> >
> >class MyClass(object):
> >
> >    def __init__(@):
> >        @.dummy = None
> >
> >OR, even better, getting *rid of it* in the parameter list, so it stops confusing people about how many parameters a method needs, and transform it into a true *operator*.
> >
> >class MyClass(object):
> >
> >    def __init__(): #takes no arguments!
> >        @.dummy = None  #the @ invokes the class object's dictionary
> >
> >That would seem to be a nice solution to the problem, really.  It doesn't become PERLish because you've made it into a genuine operator -- "self" was always a non-variable that looked like a variable and hence created an itch that couldn't be scratched.
> >
> >Anyone else have any thoughts?
>
> Guido did.  :)
> http://neopythonic.blogspot.se/2008/10/why-explicit-self-has-to-stay.html

Nice link, thanks.

I see the problem.  I was under the false impression that Python's lexer built an *abstract syntax tree* (see wikipedia for a nice description) like C does so that lexical items like functions and objects are defined.  As it stands now, Python doesn't even seem to know what an *expression* is.

Guido hasn't defined his language so that an object is defined lexically, so he's cheating a little by requiring "self" to be passed in.  If Python were to be defined more completely, all his points in reference to Bruce Eckel's suggestion would be moot.  A method would automatically (not auto*magically*) know what class they are in.

Mark


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

zipher
In reply to this post by zipher
On Tuesday, May 26, 2015 at 9:48:25 PM UTC-5, zipher wrote:

> On Tuesday, May 26, 2015 at 12:28:31 PM UTC-5, Mark Lawrence wrote:
> > On 26/05/2015 17:37, zipher wrote:
> > > Would it be prudent to rid the long-standing "argument" (pun unintended) about self and the ulterior spellings of it, by changing it into a symbol rather than a name?
> >
> > Yes, how about you taking a permanent holiday rather than bother this
> > list with more of your nonsense?
> >
> > Mark Lawrence
>
> Mr. Lawrence, could you calm down with your sadism on the list.  Our session last time ended with a lot of semen on your floor instead of in your mouth.
>
> Your bosom buddy,
>
> Mark Janssen

Arrgh.  Sorry, that was meant privately...

-m


Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Ben Finney-10
zipher <dreamingforward at gmail.com> writes:

> Arrgh.  Sorry, that was meant privately...

I'm glad we saw it publicly, so that we get more of an idea how you
treat people.

That kind of homophobic slur is inappropriate from anyone in this
community. Kindly cut it out altogether.

--
 \       ?Always do right. This will gratify some people, and astonish |
  `\                                            the rest.? ?Mark Twain |
_o__)                                                                  |
Ben Finney



Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Steven D'Aprano-11
In reply to this post by zipher
On Wednesday 27 May 2015 02:37, zipher wrote:

> Would it be prudent to rid the long-standing "argument" (pun unintended)
> about self and the ulterior spellings of it, by changing it into a symbol
> rather than a name?

No.


> Something like:
>
> class MyClass(object):
>
>     def __init__(@):
>         @.dummy = None
>
> OR, even better, getting *rid of it* in the parameter list, so it stops
> confusing people about how many parameters a method needs, and transform
> it into a true *operator*.

I think you misspelled a word. There's no "be", "tt" or "er" in "worse" :-)

All joking aside, I cannot imagine why you think that the first argument to
a method should be considered an operator. It's an argument, a named
variable, not an operator.


> class MyClass(object):
>
>     def __init__(): #takes no arguments!

But that is completely wrong. __init__ DOES take a single argument -- the
instance. Methods, it can be either bound to the instance or unbound:

py> str.upper("hello world")  # unbound method, self provided explicitly
'HELLO WORLD'
py> "hello world".upper()  # bound method, self provided automatically
'HELLO WORLD'

I suggest you study these two examples carefully.



>         @.dummy = None  #the @ invokes the class object's dictionary

It certainly shouldn't do that. It should invoke the full attribute lookup
machinery, which does far more than invoke the class __dict__. In fact, if
it invoked the class __dict__, that would *completely* break the object
oriented paradigm. Writing to the class __dict__ means that all instances
share the same value.


> That would seem to be a nice solution to the problem, really.  It doesn't
> become PERLish because you've made it into a genuine operator -- "self"
> was always a non-variable that looked like a variable and hence created an
> itch that couldn't be scratched.

That is completely wrong. self is, and always has been, a real variable.
That's why you can call it anything you like -- self is just the convention,
nothing more.



--
Steven



Reply | Threaded
Open this post in threaded view
|

should "self" be changed?

Steven D'Aprano-11
In reply to this post by Marko Rauhamaa
On Wednesday 27 May 2015 05:46, Marko Rauhamaa wrote:

> Python's practice works. However, a small problem is presented by nested
> classes:
>
>     class Connection:
>         def __init__(self):
>             class Idle:
>                 def signal_start(self):
>                     # how to refer to the outer self
>                     :
>             :


The best solution is not to use nested classes, but if you really must:


class Connection:
    def __init__(self):
        class Idle:
            def signal_start(this):
                # this is the Idle instance;
                # self is the Connection instance



--
Steve



123