473,902 Members | 3,407 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

the annoying, verbose self

Is there any trick to get rid of having to type the annoying,
character-eating "self." prefix everywhere in a class? Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not crucial especially for @ prefix is better-
looking than self.

But things grow -- is there any metaprogramming tricks or whatnot we
can throw on the self?

Cheers,
Alexy
Nov 21 '07
84 7268
MonkeeSage wrote:
The issue of lexical scope still looms large on the horizon. How does
one distinguish between attributes (as scoped by the "with" clause),
local/global variables, and function/method calls? There doesn't seem
to be an easy way. You'd need multiple passes over the data to
determine various scopes -- and for what, to save typing a few
characters? And even if implemented, it would mean hiding the
complexity of the resolution, which is not a good thing.

Regards,
Jordan
Does this address your concerns?

The idea being that "with self" use
creates a new namespace:
newGlobal= oldGlobal + oldLocal
newLocal= names from self

Similarly, "with math" creates a newer
namespace:
newerGlobal= newGlobal + newLocal
newerLocal= names from math

My guess is that there would be little
use for nesting the
"with".
Colin W.
Nov 25 '07 #61
MonkeeSage wrote:
The issue of lexical scope still looms large on the horizon. How does
one distinguish between attributes (as scoped by the "with" clause),
local/global variables, and function/method calls? There doesn't seem
to be an easy way. You'd need multiple passes over the data to
determine various scopes -- and for what, to save typing a few
characters? And even if implemented, it would mean hiding the
complexity of the resolution, which is not a good thing.

Regards,
Jordan
Does this address your concerns?

The idea being that "with self" use
creates a new namespace:
newGlobal= oldGlobal + oldLocal
newLocal= names from self

Similarly, "with math" creates a newer
namespace:
newerGlobal= newGlobal + newLocal
newerLocal= names from math

My guess is that there would be little
use for nesting the
"with".
Colin W.

Nov 25 '07 #62
On Nov 24, 10:55 am, jakub silar <jakub.si...@vo lny.czwrote:
BJörn Lindqvist wrote:
On Nov 22, 2007 2:08 PM, Colin J. Williams <c...@sympatico .cawrote:
>bearophileH... @lycos.com wrote:
>>Alexy:
>>>Sometimes I
avoid OO just not to deal with its verbosity. In fact, I try to use
Ruby anywhere speed is not crucial especially for @ prefix is better-
looking than self.
>>Ruby speed will increase, don't worry, as more people will use it.
>>Bye,
bearophile
>I don't see this as a big deal, but
The big deal is that "self." occupies important horizontal screen real
estate. That is, it is usually not self in itself that is problematic,
but the overflowing lines is. Take this silly vector class for
example:
1 class Vector:
2 def __init__(self, x, y, z):
3 self.x = x
4 self.y = y
5 self.z = z
6 def abs(self):
7 return math.sqrt(self. x * self.x + self.y * self.y +
self.z * self.z)
Line 7 is 82 characters long which is, if you care about the
readability of your code, a very real problem because the line is to
long. So you break it:
7 return math.sqrt(self. x * self.x +
self.y * self.y +
self.z * self.z)
Better, but definitely not as nice as it would have been with a
shorter self prefix like you propose. And in my eyes, having to break
lines like this instantly makes the code much less attractive. There
is probably not a single language in existance in which wrapping lines
doesn't make the code uglier.
I also notice that the lines in your mail are nicely broken at about
column 45, probably because you are typing on a PDA or similar? In
those situations, where you require much shorter lines than the
standard 78 characters, for example when typesetting code examples for
a book, the problem with line breaks is even worse.
>suppose that the syntax were
expanded so that, in a method, a dot
".", as a precursor to an identifier,
was treated as "self." is currently treated?
I like that a lot. This saves 12 characters for the original example
and removes the need to wrap it.
7 return math.sqrt(.x * .x + .y * .y + .z * .z)
+1 Readability counts, even on small screens.

Below is my coding standard - I'm lazy, even lazy to persuade
comutinties into strange (imho) language syntax extensions.

class Vector:
def __init__(s, x, y, z):
s.x = x
s.y = y
s.z = z
def abs(s):
return math.sqrt(s.x * s.x + s.y * s.y + s.z * s.z)

Admit that changing habits may be more difficult then to change a
language syntax.

Jakub

occasional lamerish Python user
Well you're not the laziest. Here's mine:

class Vector:
def __init__(self, *data):
self.data = data
def abs(self):
return math.sqrt(sum(x *x for x in self.data))

Hey I'm so lazy it's untested :)
However I've got standards: I wouldn't swap 'self' for 's'.

--
Arnaud

Nov 25 '07 #63
On Nov 24, 2007 11:55 AM, jakub silar <ja*********@vo lny.czwrote:
Below is my coding standard - I'm lazy, even lazy to persuade
comutinties into strange (imho) language syntax extensions.
class Vector:
def __init__(s, x, y, z):
s.x = x
s.y = y
s.z = z
def abs(s):
return math.sqrt(s.x * s.x + s.y * s.y + s.z * s.z)

Admit that changing habits may be more difficult then to change a
language syntax.
Yes, indeed. A self-reference prefix like "s", "T", "_" or even "my"
would be enough characters shorter than "self." But self *is* the
convention and just because the language allows you to break it
doesn't mean that it is not horribly wrong to do so. :)
--
mvh Björn
Nov 26 '07 #64
Ton van Vliet a écrit :
On 24 Nov 2007 13:56:37 GMT, Marc 'BlackJack' Rintsch <bj****@gmx.net >
wrote:
(snip)
>>So::

def meth(self):
using self:
tmp = raw_input('Ente r age: ')
age = int(tmp)

becomes::

def meth(self):
using self:
self.tmp = self.raw_input( 'Enter age: ')
self.age = self.int(tmp)

Binding `tmp` unnecessarily to the object and trying to get `raw_input()`
and `int()` from the object. Ouch. :-)


Absolutely.

However, I was more thinking in terms of attributes only
Too bad : in Python, everything's an object, so 'methods' are attributes
too.
Nov 26 '07 #65
samwyse a écrit :
(snip)
>
Besides Pascal, Visual Basic also offers a 'with' statement that
behaves almost in this way. That in itself should be an indication
that the whole thing is a bad idea. ;-)
FWIW, Javascript has it too - and it's considered a BadPractice(tm) to
use it...
Nov 26 '07 #66
Ton van Vliet a écrit :
On 24 Nov 2007 16:07:18 GMT, Duncan Booth
<du**********@i nvalid.invalidw rote:

>>Ton van Vliet <sh***********@ green.meadowwro te:

>>>It would boil down to choice: explicit/speed vs implicit/readability

No, it would boil down to explicit+speed+ readability+mai ntainability vs
implicit+erro r prone.


It would not be a full fledged *implicit*, but only used in small
areas where many self's are coming together, and possibly clutter
readability (a subjective classification anyhow) and even could
degrade (code) maintainability .

In which case explicitely making local aliases is not too much work, and
way more readable.
Nov 26 '07 #67
Patrick Mullen a écrit :
(snip)
Still an unnecessary lookup on tmp though :) And it would be useless
to use it for one assignment, the idea is to eliminate all the typing
with this:

self.var1 = 5
self.var2 = "a value"
self.var3 = stuff
self.var4 = [2,54,7,7]
self.var5 = "dingaling"
self.var6 = 6.4
self.var7 = 1
self.var8 = False
self.var9 = True
self.__dict__.u pdate(dict(var1 =5, var2="a value", var3 = stuff, <etc>))

Someone else ? Or are we done with this DeadHorse ?
Nov 26 '07 #68
samwyse a écrit :
(snip)
>
Actually, the chained dots are solving a completely different problem,
that of refactoring a collection of functions that use global vars
into a class.
Using globals to maintain state between functions being bad practice in
most cases, I don't see any reason to encourage it by providing some
builtin support.
Nov 26 '07 #69
On Mon, 26 Nov 2007 20:14:50 +0100, Bruno Desthuilliers
<bd************ *****@free.quel quepart.frwrote :
>However, I was more thinking in terms of attributes only

Too bad : in Python, everything's an object, so 'methods' are attributes
too.
Right, but I'm sure *you* know a way to distinguish between them (I'm
just a beginner ;-)

--
Ton
Nov 26 '07 #70

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.