Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #91253 > unrolled thread

should "self" be changed?

Started byzipher <dreamingforward@gmail.com>
First post2015-05-26 09:37 -0700
Last post2015-05-27 15:17 +1000
Articles 8 on this page of 48 — 21 participants

Back to article view | Back to comp.lang.python


Contents

  should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-26 09:37 -0700
    Re: should "self" be changed? Laura Creighton <lac@openend.se> - 2015-05-26 18:57 +0200
      Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-26 20:01 -0700
      Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-26 20:15 -0700
    Re: should "self" be changed? Laurent Pointal <laurent.pointal@free.fr> - 2015-05-26 18:59 +0200
    Re: should "self" be changed? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-26 18:28 +0100
      Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-26 19:48 -0700
        Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-26 20:17 -0700
          Re: should "self" be changed? Ben Finney <ben+python@benfinney.id.au> - 2015-05-27 14:39 +1000
            Re: should "self" be changed? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-27 15:47 +1000
              Re: should "self" be changed? Ben Finney <ben+python@benfinney.id.au> - 2015-05-27 21:29 +1000
                Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-27 05:40 -0700
                  Re: should "self" be changed? Todd <toddrjen@gmail.com> - 2015-05-27 15:00 +0200
                    Re: should "self" be changed? Grant Edwards <invalid@invalid.invalid> - 2015-05-27 14:19 +0000
                    Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-30 16:18 -0700
              Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-30 16:10 -0700
            Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-30 16:13 -0700
    Re: should "self" be changed? Chris Angelico <rosuav@gmail.com> - 2015-05-27 03:31 +1000
    Re: should "self" be changed? random832@fastmail.us - 2015-05-26 14:11 -0400
    Re: should "self" be changed? Marko Rauhamaa <marko@pacujo.net> - 2015-05-26 22:46 +0300
      Re: should "self" be changed? Ned Batchelder <ned@nedbatchelder.com> - 2015-05-26 13:04 -0700
        Re: should "self" be changed? Marko Rauhamaa <marko@pacujo.net> - 2015-05-26 23:36 +0300
          Re: should "self" be changed? Anssi Saari <as@sci.fi> - 2015-05-28 17:07 +0300
            Re: should "self" be changed? Marko Rauhamaa <marko@pacujo.net> - 2015-05-28 18:01 +0300
              Re: should "self" be changed? Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-28 09:40 -0600
                Re: should "self" be changed? Marko Rauhamaa <marko@pacujo.net> - 2015-05-28 19:59 +0300
                  Re: should "self" be changed? Chris Angelico <rosuav@gmail.com> - 2015-05-29 03:06 +1000
                  Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-30 16:39 -0700
              Re: should "self" be changed? Steven D'Aprano <steve@pearwood.info> - 2015-05-29 12:00 +1000
                Re: should "self" be changed? Steven D'Aprano <steve@pearwood.info> - 2015-05-29 15:46 +1000
                Re: should "self" be changed? Steven D'Aprano <steve@pearwood.info> - 2015-06-03 02:50 +1000
                  Re: should "self" be changed? "Dr. BigCock" <dreamingforward@gmail.com> - 2015-06-02 10:16 -0700
                  Re: should "self" be changed? Marko Rauhamaa <marko@pacujo.net> - 2015-06-02 20:19 +0300
                    Re: should "self" be changed? "Dr. Bigcock" <dreamingforward@gmail.com> - 2015-06-02 11:02 -0700
                    Re: should "self" be changed? Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-02 19:39 -0600
                    Re: should "self" be changed? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-06-03 17:05 +1000
      Re: should "self" be changed? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-27 15:20 +1000
    Re: should "self" be changed? garabik-news-2005-05@kassiopeia.juls.savba.sk - 2015-05-26 20:26 +0000
      Re: should "self" be changed? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-26 21:45 +0100
        Re: should "self" be changed? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-27 15:23 +1000
          Re: should "self" be changed? Chris Angelico <rosuav@gmail.com> - 2015-05-27 16:32 +1000
            Re: should "self" be changed? Marko Rauhamaa <marko@pacujo.net> - 2015-05-27 10:39 +0300
              Re: should "self" be changed? Chris Angelico <rosuav@gmail.com> - 2015-05-27 18:20 +1000
              Re: should "self" be changed? zipher <dreamingforward@gmail.com> - 2015-05-30 16:15 -0700
          Re: should "self" be changed? Terry Reedy <tjreedy@udel.edu> - 2015-05-27 17:59 -0400
      Re: should "self" be changed? Vito De Tullio <vito.detullio@gmail.com> - 2015-05-26 23:17 +0200
      Re: should "self" be changed? Tim Chase <python.list@tim.thechases.com> - 2015-05-26 16:10 -0500
    Re: should "self" be changed? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-27 15:17 +1000

Page 3 of 3 — ← Prev page 1 2 [3]


#91284

FromChris Angelico <rosuav@gmail.com>
Date2015-05-27 16:32 +1000
Message-ID<mailman.73.1432708376.5151.python-list@python.org>
In reply to#91282
On Wed, May 27, 2015 at 3:23 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Wednesday 27 May 2015 06:45, Mark Lawrence wrote:
>
>> Apart from breaking all the tools that rely on "self" being spelt "self"
>> this looks like an excellent idea.
>
> Tools which rely on self being spelled "self" are already broken. It's a
> convention, nothing more, and there are various good reasons for breaking
> the convention:
>
> - metaclasses
> - classmethods
> - custom descriptors
> - nested classes

If it truly relies on it, yes. But if I see a function that has "self"
as its first parameter, I'm going to read it as a (probable) method
rather than a stand-alone function, and it wouldn't surprise me if
introspection and/or source code parsing made the same assumption.
It's as strong a convention as "don't touch the ones that begin with
an underscore", which is broken by the namedtuple due to namespacing
requirements, but otherwise is fairly dependable (eg if tab completion
skipped the underscore attributes, it'd be a bit less useful on
namedtuples, but probably more practical overall). Using some other
name in place of "self" should definitely remain *possible*, but not
commonly done.

ChrisA

[toc] | [prev] | [next] | [standalone]


#91288

FromMarko Rauhamaa <marko@pacujo.net>
Date2015-05-27 10:39 +0300
Message-ID<874mmybhb7.fsf@elektro.pacujo.net>
In reply to#91284
Chris Angelico <rosuav@gmail.com>:

> Using some other name in place of "self" should definitely remain
> *possible*, but not commonly done.

You are effectively making the argument that Python has made a mistake
by not giving "self" a special, language-level status.


Marko

[toc] | [prev] | [next] | [standalone]


#91290

FromChris Angelico <rosuav@gmail.com>
Date2015-05-27 18:20 +1000
Message-ID<mailman.76.1432714830.5151.python-list@python.org>
In reply to#91288
On Wed, May 27, 2015 at 5:39 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> Using some other name in place of "self" should definitely remain
>> *possible*, but not commonly done.
>
> You are effectively making the argument that Python has made a mistake
> by not giving "self" a special, language-level status.

Uhh... no I'm not. I'm saying it should be possible to use some other
name instead of "self", which means that Python got it right by not
making it special.

ChrisA

[toc] | [prev] | [next] | [standalone]


#91551

Fromzipher <dreamingforward@gmail.com>
Date2015-05-30 16:15 -0700
Message-ID<1f630a51-cfad-4926-a739-7d009050c97d@googlegroups.com>
In reply to#91288
On Wednesday, May 27, 2015 at 2:39:21 AM UTC-5, Marko Rauhamaa wrote:
> Chris Angelico <rosuav@gmail.com>:
> 
> > Using some other name in place of "self" should definitely remain
> > *possible*, but not commonly done.
> 
> You are effectively making the argument that Python has made a mistake
> by not giving "self" a special, language-level status.

I'm making that claim.  Guido's arguments are based on a simple lexical definition of the language.  If the lexical definition were sophisticated enough to feed into GCC as a front-end, for example, then it wouldn't have to be so abnormal.  It's a short-cut for a less mature language.

Mark

[toc] | [prev] | [next] | [standalone]


#91326

FromTerry Reedy <tjreedy@udel.edu>
Date2015-05-27 17:59 -0400
Message-ID<mailman.101.1432763977.5151.python-list@python.org>
In reply to#91282
On 5/27/2015 2:32 AM, Chris Angelico wrote:
> On Wed, May 27, 2015 at 3:23 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Wednesday 27 May 2015 06:45, Mark Lawrence wrote:
>>
>>> Apart from breaking all the tools that rely on "self" being spelt "self"
>>> this looks like an excellent idea.
>>
>> Tools which rely on self being spelled "self" are already broken. It's a
>> convention, nothing more, and there are various good reasons for breaking
>> the convention:
>>
>> - metaclasses
>> - classmethods
>> - custom descriptors
>> - nested classes
>
> If it truly relies on it, yes. But if I see a function that has "self"
> as its first parameter, I'm going to read it as a (probable) method
> rather than a stand-alone function, and it wouldn't surprise me if
> introspection and/or source code parsing made the same assumption.

The Idlelib calltips function does not look at names.  It leaves the 
signature of functions as is and removes the first name, whatever it is, 
of bound methods, including bound class methods.  See 
idlelib.CallTips.get_argspec for details. To make sure there is no name 
assumption, test_calltips.py tests that the first name, not 'self', is 
the name removed.  One test method, Tc.t6, has function signature "(no, 
self)", which makes the bound method signature "(self)".


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]


#91267

FromVito De Tullio <vito.detullio@gmail.com>
Date2015-05-26 23:17 +0200
Message-ID<mailman.67.1432675016.5151.python-list@python.org>
In reply to#91262
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

[toc] | [prev] | [next] | [standalone]


#91268

FromTim Chase <python.list@tim.thechases.com>
Date2015-05-26 16:10 -0500
Message-ID<mailman.68.1432676764.5151.python-list@python.org>
In reply to#91262
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.


[toc] | [prev] | [next] | [standalone]


#91280

FromSteven D'Aprano <steve+comp.lang.python@pearwood.info>
Date2015-05-27 15:17 +1000
Message-ID<55655380$0$2796$c3e8da3$76491128@news.astraweb.com>
In reply to#91253
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

[toc] | [prev] | [standalone]


Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.python


csiph-web