PEP 318

Jacek Generowicz jacek.generowicz at cern.ch
Mon Mar 22 16:56:43 CET 2004


"John Roth" <newsgroups at jhrothjr.com> writes:

> "Jacek Generowicz" <jacek.generowicz at cern.ch> wrote in message
> news:tyfisgx6wfo.fsf at pcepsft001.cern.ch...
> > Nicolas Fleury <nid_oizo at yahoo.com_removethe_> writes:
> >

> > I teach Python courses ... 

[...]

> > fairly early on in the treatment of classes, I point out that
> > there is nothing special about the name "self", but I usually ask
> > the students what they make of it, before offering any of my own
> > comments.
> 
> Excellent class design! When I was doing classes, I found
> one of the most important questions I could ask myself in
> the after-the-class analysis was "what could I have said
> earlier that would have dealt with this question / confusion?"

[...]

> > > - Give a warning for all methods with first parameter not named "self"
> > > in next versions of Python.
> >
> > That would be acceptable ...
> 
> Only if the intention is to move to making it a built-in. Otherwise there
> really are people who use some other name than self (usually to save
> keystrokes.)

... just after I say that there is nothing special about "self" (in my
Python courses), I plead that, even though you are allowed to use any
name you like, you should use "self", and nothing but "self", on the
grounds that this will ensure that other Python programmers (which
includes yourself at a later date) will immediately understand what
you are doing; while you are likely to cause lots of confusion if you
use anything other than "self". At this point I usually re-iterate
that clearly showing your intentions, is very much good Python
style. (If I'm feeling in "that sort of mood" I might even point out
that if you want to save keystrokes, then you know where you can find
Perl.)

If a warning such as Nicolas proposes were introduced, I hope that it
would be suppressable. If so, I suspect that it would be a very useful
feature. I think that making the name "self" obligatory would run very
much against some of the basic Python philosophies.



More information about the Python-list mailing list