Is it advisable to replace 'self' with '_' or 'I' or something shorter?
Jonathan P.
for code readability, however it tends to make code lines
too long. Since 'self' is just a convention, I wonder if
people out there have tried replacing it with a one-character
equivalent without encountering any problems.
I was thinking of using '_' ('I' is a distant second
choice) instead of self. Comments?
Kevin Altis
other people to read your source if don't use 'self', so it isn't advisable.
You might consider binding a "macro" to type out "self." if typing the
characters bothers you or use some funky character that doesn't occur in
your source and do a global replace later on, but that is probably
error-prone.
ka
"Jonathan P." <jbper...@yahoo.com> wrote in message
news:f57664b9.03011...@posting.google.com...
Grant Edwards
> The most common is probably 's'. However, it makes it more difficult for
> other people to read your source if don't use 'self', so it isn't advisable.
> You might consider binding a "macro" to type out "self." if typing the
> characters bothers you
I don't know about the OP, but I don't care about the typing. That's NRE.
It's the reading that's a problem. If you've expressions like
(((a+b)/c)*(d-x))-y
they end up looking like
(((self.a+self.b)/self.c)*(self.d-self.x))-self.y
I have a much easier time grokking the former. In some cases you end up
with lines 100+ characters long instead of 20 or 30.
Using local variables helps...
--
Grant Edwards grante Yow! I want to kill
at everyone here with a cute
visi.com colorful Hydrogen Bomb!!
Terry Reedy
> for code readability, however it tends to make code lines
> too long. Since 'self' is just a convention, I wonder if
> people out there have tried replacing it with a one-character
> equivalent without encountering any problems.
How could there be? (Rhetorical question)
>
> I was thinking of using '_' ('I' is a distant second
> choice) instead of self. Comments?
I routinely use s and o for self and other in private code. 's.' is
very easy for me to type (although having 'self.' in a macro or paste
buffer might work as well). The only problem I have had is a couple
of people jabbing at me when saying so publicly. But I plan to
continue anyway. Good luck.
Terry J. Reedy
Carl Banks
This must be self-loathing week. If you're going to do that, I
recommend that you not use the underscore. The underscore has come to
be used for internationalization (with good reason, I would say). If
you use the underscore, you're now violating two community standards.
'I' is probably the best one character self; at least it's somewhat
descriptive and reminiscent of 'self'.
I think it's most wise not to deviate from self, though.
--
CARL BANKS
Edward K. Ream
I often use the following idiom for methods in Leo:
def spam(self,...):
v = self
# Now use v instead of self
The idea is to use one-letter codes for common classes. Leo uses c for
"commanders", f for frames, t for Tk.Text widgets or "tnodes", v for
"vnodes", u for "undoer" objects, etc. With this idiom, objects of the
class in which the method exists are handled just like all other objects.
It saves typing and makes the type of all objects clear.
One could use:
def spam,(v,...):
# etc.
instead, but that would violate the coding guidelines (and pychecker would
complain by default).
This scheme is simple, clear, concise, effective. It has no drawbacks that
I know of.
Edward
--------------------------------------------------------------------
Edward K. Ream email: edr...@tds.net
Leo: Literate Editor with Outlines
Leo: http://personalpages.tds.net/~edream/front.html
--------------------------------------------------------------------
Just
Grant Edwards <gra...@visi.com> wrote:
> In article <ThZT9.98$B62....@news.uswest.net>, Kevin Altis wrote:
>
> > The most common is probably 's'. However, it makes it more difficult for
> > other people to read your source if don't use 'self', so it isn't advisable.
> > You might consider binding a "macro" to type out "self." if typing the
> > characters bothers you
>
> I don't know about the OP, but I don't care about the typing. That's NRE.
> It's the reading that's a problem. If you've expressions like
>
> (((a+b)/c)*(d-x))-y
>
> they end up looking like
>
> (((self.a+self.b)/self.c)*(self.d-self.x))-self.y
>
> I have a much easier time grokking the former. In some cases you end up
> with lines 100+ characters long instead of 20 or 30.
>
> Using local variables helps...
Yup. To me the above looks like someone is using instance variables as
if they are globals and I've seen beginners do that many times. IMHO,
using instance variables for actual state, and passing other values as
arguments to methods is often much better style. And in cases you really
*do* need lots of instance variables, temporarily binding them to local
vars can help. Sometimes bundling several variables in a tuple helps, as
in this snippet from a module of mine:
def inverse(self):
"Return the inverse transform."
if self.__affine == (1, 0, 0, 1, 0, 0):
return self
xx, xy, yx, yy, dx, dy = self.__affine
det = float(xx*yy - yx*xy)
xx, xy, yx, yy = yy/det, -xy/det, -yx/det, xx/det
dx, dy = -xx*dx - yx*dy, -xy*dx - yy*dy
return self.__class__(xx, xy, yx, yy, dx, dy)
Just
Andrew Dalke
> If you've expressions like
>
> (((a+b)/c)*(d-x))-y
>
> they end up looking like
>
> (((self.a+self.b)/self.c)*(self.d-self.x))-self.y
>
> I have a much easier time grokking the former. In some cases you end up
> with lines 100+ characters long instead of 20 or 30.
Of course if you have small variable names then the self. dominates
the name. However, more realistic code uses more descriptive names,
as in (from wave.py)
self._soundpos = self._soundpos + len(data) // (self._nchannels *
self._sampwidth)
(*uggh* I've haven't done much C++ code in >5 years and the // *still*
looks like a comment to me, instead of integer division.)
At other times the code is more easily read as smaller components
scaled_value = (self.a + self.b)/self.c
transformed = scaled_value * (self.d - self.x) - self.y
> Using local variables helps...
As in from difflib
a, b, b2j, isbjunk = self.a, self.b, self.b2j, self.isbjunk
Andrew
da...@dalkescientific.com
Erik Max Francis
I would consider any systematic use of a self parameter named something
other than `self' a near perversity. You're just begging for confusion.
If you want to rebind it in the method, fine.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Life is not a spectacle or a feast; it is a predicament.
\__/ George Santayana
CSBuddy / http://www.alcyone.com/pyos/csbuddy/
A Counter-Strike server log file monitor in Python.
Dan Schmidt
I used to use _, but I decided to be a good citizen and use self these
days. My main problem with self is not that it takes more time to
type but that it looks like just another word when I'm scanning code,
which distracts me from the 'real' variables. So I modifed my emacs
python-mode so that self is displayed in a different color, and I can
deal with it a lot better now.
Dan
Erik Max Francis
> I used to use _, but I decided to be a good citizen and use self these
> days. My main problem with self is not that it takes more time to
> type but that it looks like just another word when I'm scanning code,
> which distracts me from the 'real' variables. So I modifed my emacs
> python-mode so that self is displayed in a different color, and I can
> deal with it a lot better now.
Try getting the latest version of python-mode.el. It already highlights
`self' in this way.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Love is like war: easy to begin but very hard to stop.
\__/ H.L. Mencken
Church / http://www.alcyone.com/pyos/church/
A lambda calculus explorer in Python.
Jonathan P.
One compromise I can think of would be to just use 'self'
all the time and in the isolated cases where it would
lead to unbearably long (and unreadable) lines, create an
alias variable for the offending attribute.
Erik Max Francis
> One compromise I can think of would be to just use 'self'
> all the time and in the isolated cases where it would
> lead to unbearably long (and unreadable) lines, create an
> alias variable for the offending attribute.
_And_ always do that in local scope. Already you see this done,
especially if you have to translate involved mathematical equations to
code; you use shorter versions of the names so the expressions don't
become enormous. But in the parameter declaration, the self argument
should always be nothing other than `self'.
As others have pointed out, there are good, solid reasons for not using
`_' in any case -- it's used in internationalization, the Python
interactive interpreter uses it for the last calculated expression, etc.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Only the winners decide what were war crimes.
\__/ Gary Wills
Bosskey.net: Counter-Strike / http://www.bosskey.net/cs/
A personal guide to Counter-Strike.
Dan Schmidt
| Dan Schmidt wrote:
|
| > I used to use _, but I decided to be a good citizen and use self
| > these days. My main problem with self is not that it takes more
| > time to type but that it looks like just another word when I'm
| > scanning code, which distracts me from the 'real' variables. So I
| > modifed my emacs python-mode so that self is displayed in a
| > different color, and I can deal with it a lot better now.
|
| Try getting the latest version of python-mode.el. It already
| highlights `self' in this way.
I'm using python-mode 4.6 from <http://www.python.org/emacs/python-mode/>
and it does not appear to highlight 'self'. Is there a newer version
available, or am I missing something?
Dan
Mel Wilson
Erik Max Francis <m...@alcyone.com> wrote:
>"Jonathan P." wrote:
>
>> I agree with the fact that explicit use of self is good
>> for code readability, however it tends to make code lines
>> too long. Since 'self' is just a convention, I wonder if
>> people out there have tried replacing it with a one-character
>> equivalent without encountering any problems.
>>
>> I was thinking of using '_' ('I' is a distant second
>> choice) instead of self. Comments?
>
>I would consider any systematic use of a self parameter named something
>other than `self' a near perversity. You're just begging for confusion.
>
>If you want to rebind it in the method, fine.
As a tiny addition: I seem to find it more useful to
rebind entire variables, so that I write
t = self.tree
t.yadayada()
t.usw ()
rather than
s = self
s.tree.yadayada()
s.tree.usw ()
That's dummy code, of course .. real code would look like:
t = self.tree
i = t.AppendItem (parent, text)
t.SetPyData (i, data)
t.EnsureVisible (i)
A shortcut to an important local variable seems more
motivated, somehow.
Regards, Mel.
Lee Harr
>
> As a tiny addition: I seem to find it more useful to
> rebind entire variables, so that I write
>
> t = self.tree
> t.yadayada()
> t.usw ()
>
> rather than
>
> s = self
> s.tree.yadayada()
> s.tree.usw ()
>
Exactly. I believe it can also be faster.
Might be important in a tight loop.
je...@compy.attbi.com
> As a tiny addition: I seem to find it more useful to
> rebind entire variables, so that I write
>
> t = self.tree
> t.yadayada()
> t.usw ()
>
> rather than
>
> s = self
> s.tree.yadayada()
> s.tree.usw ()
This hews close to one of my pet peeves, which I see a *lot* of in Windows
C++ code, anything that looks like this:
this->frame.lexFromMextex[1].account[UGLY_CONSTANT]++.EXTRACT_NUMBER(2);
For the love of pete, rebind a few things so it looks more sensible. (The
compiler has to anyhow in compiled languages like C++...)
In particular, take the opportunity to do something meaningful if
possible. Maybe "this->frame.lexFromMextex" is really the
"billingFrameIterator" or something. (You'd probably abbreviate Iterator
to It, but still...)
Erik Max Francis
> I'm using python-mode 4.6 from
> <http://www.python.org/emacs/python-mode/>
> and it does not appear to highlight 'self'. Is there a newer version
> available, or am I missing something?
I'm using version 4.28 and it does. Weird.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Describe a circle, stroke its back and it turns vicious.
\__/ Ionesco
The laws list / http://www.alcyone.com/max/physics/laws/
Laws, rules, principles, effects, paradoxes, etc. in physics.
oofoe
jbper...@yahoo.com (Jonathan P.) wrote in message news:<f57664b9.03011...@posting.google.com>...
> I agree with the fact that explicit use of self is good
> for code readability, however it tends to make code lines
> too long. Since 'self' is just a convention, I wonder if
> people out there have tried replacing it with a one-character
> equivalent without encountering any problems.
I dislike the word 'self' for the method's object argument. It's
clumsy to say and lends an unwarranted arrogance and formality
to the method call. I prefer the much more friendly name 'my'.
It's one letter longer than your preferred length, but it's
very natural. To paraphrase Mark Twain, it's a name that's willing
to roll up its sleeves, spit on its hands and get right to work,
instead of setting out for a scenic sail across a vast ocean of
verbose bureaucratese. See for yourself:
class uptight:
name_christian = "Victor"
name_family = "Blendeloquene II"
age_in_years = 56
def describe(self):
print "%s %s is %s years old." % (
self.name_christian,
self.name_family,
self.age_in_years)
class cool:
name = "Jack Flash"
nick = "Jumpin'"
sign = "aquarius"
def hi(my): print "I'm " + my.name + ", call me " + my.nick + "."
def baby(my): my.hi(); print "I'm an " + my.sign + ", how about you?"
a = uptight(); a.describe(); print
k = cool(); k.baby()
As you can see from the code samples above, the second class (the
'cool' one) is much easier to read and far more compact than the
'correct', but thoroughly uptight, version at the top. Notice also
the expressiveness of the code. The cool class has already got
the next dance lined up in eight lines of code before the uptight
class has managed to finish introducing himself in ten.
A key point is that the 'my' name connotes possessiveness in the
created clause, whereas the 'self' name can only form a clumsy
compound name: "my.name" as opposed to "self.name".
The one possible fly in the ointment is that many writers of
introductory computer programming texts like to use 'my' as a prefix
to a user written function, such as 'myPrint()' or 'myOpen()' or
even 'myHeadIsFilledWithAir()'. Since no working programmer follows
this practice for longer than ten minutes after finishing CSCI101, I
propose that the textbook authors use the 'self' as a prefix instead,
clearing the way for 'my' to enter the common lexicon.
I'm only half joking.
Jos'h
Max M
> Hi!
>
> jbper...@yahoo.com (Jonathan P.) wrote in message news:<f57664b9.03011...@posting.google.com>...
>
>>I agree with the fact that explicit use of self is good
>>for code readability, however it tends to make code lines
>>too long. Since 'self' is just a convention, I wonder if
>>people out there have tried replacing it with a one-character
>>equivalent without encountering any problems.
>
>
> I dislike the word 'self' for the method's object argument. It's
> clumsy to say and lends an unwarranted arrogance and formality
> to the method call. I prefer the much more friendly name 'my'.
You are fighting an uphill battle against the windmills here!
Use "self" and get over it ;-)
If you ever want your code to be seen by others, it is a bad idea. Why
should they read "obfuscated" code? If you ever want to read other
peoples code, you won't be used to see self. Also a bad idea.
regards Max M
--
hilsen/regards Max M
http://www.futureport.dk/
Fremtiden, videnskab, skeptiscisme og transhumanisme
Carl Banks
> Hi!
>
> jbper...@yahoo.com (Jonathan P.) wrote in message news:<f57664b9.03011...@posting.google.com>...
>> I agree with the fact that explicit use of self is good
>> for code readability, however it tends to make code lines
>> too long. Since 'self' is just a convention, I wonder if
>> people out there have tried replacing it with a one-character
>> equivalent without encountering any problems.
>
> I dislike the word 'self' for the method's object argument. It's
> clumsy to say and lends an unwarranted arrogance and formality
> to the method call. I prefer the much more friendly name 'my'.
> It's one letter longer than your preferred length, but it's
> very natural. To paraphrase Mark Twain, it's a name that's willing
> to roll up its sleeves, spit on its hands and get right to work,
> instead of setting out for a scenic sail across a vast ocean of
> verbose bureaucratese. See for yourself:
>
>
> I'm only half joking.
If I were starting a new language from scratch, I might actually go
for this convention. Although the rule of thumb is that variable
names should be nouns, having the dispatching object be an adjective
is a nice way to set it apart. It's also short.
(Actually, if I were starting a new language it would use
multimethods, but that's another story.)
But I always thought "self" was one of those conventions it's best not
to stray from.
--
CARL BANKS
Erik Max Francis
> But I always thought "self" was one of those conventions it's best not
> to stray from.
Indeed. In any programming language, it's always advisable to follow
the coding style that's being used in the code you're editing,
regardless of what that style is (if you don't like the style,
convincing others to change is better than just being maverick).
The use of the identifier `self' for that "self" argument is so
pervasive (see? We even call it the "self" argument) that it's almost a
perversion to use something else.
Temporarily binding shorter names to long things for convenience is one
thing, and is commendable when appropriate, but seeing anything other
than `self' as the first argument in a standard method is a crime
against nature :-).
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, USA / 37 20 N 121 53 W / &tSftDotIotE
/ \ Ride / Ride this wave of mine
\__/ Res
Physics reference / http://www.alcyone.com/max/reference/physics/
A physics reference.