473,882 Members | 1,576 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 7261
Iain King <ia******@gmail .comwrote:
FTR, I won't be using this :) I do like this syntax though:

class Vector:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
def abs(self):
using self:
return math.sqrt(.x*.x + .y*.y + .z*.z)
It is a bit verbose though. This variant is shorter on my system[*]:

class Vector:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
def abs(self):
return math.sqrt(self. x*self.x + self.y*self.y + self.z*self.z)
[*] Windows, they are the same length on Linux.

:)
Nov 27 '07 #81
On Nov 27, 12:03 pm, Duncan Booth <duncan.bo...@i nvalid.invalid>
wrote:
Iain King <iaink...@gmail .comwrote:
FTR, I won't be using this :) I do like this syntax though:
class Vector:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
def abs(self):
using self:
return math.sqrt(.x*.x + .y*.y + .z*.z)

It is a bit verbose though. This variant is shorter on my system[*]:

class Vector:
def __init__(self, x, y, z):
self.x = x
self.y = y
self.z = z
def abs(self):
return math.sqrt(self. x*self.x + self.y*self.y + self.z*self.z)
[*] Windows, they are the same length on Linux.

:)
Yeah, in this example. Another would be

using NetworkConnecti on:
.address = "127.0.0.1"
.port = "8080"
.connect()
using .connection
while .read():
do something
.disconnect()

I doubt anything like this will take though, since you can write
similar code with 'with' and assigning a long name to a short one.

Iain

Nov 27 '07 #82
On 2007-11-26, Bruno Desthuilliers <bd************ *****@free.quel quepart.frwrote :
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 ?
I was really upset about having to type 'self' all the time,
until I learned that in ABC, one of Python's precursors, you had
to use '__anInstanceOf _This_TYPE_or_M aybe_A__SubClas sOfItInstead_ar g0_'.

--
Neil Cerutti
Sermon Outline: I. Delineate your fear II. Disown your fear III. Displace your
rear --Church Bulletin Blooper
Nov 27 '07 #83
On Tue, 27 Nov 2007 10:11:48 +0100, Bruno Desthuilliers wrote:
Fine. Now since Python let you define your own callable types and your
own descriptors, you can as well have an attribute that behave just like
a method without being an instance of any of the method types - so the
above test defeats duck typing. And since you can have callable
attributes that are definitively not methods, you can't rely on the fact
that an attribute is callable neither.
I did say the usual way was to call it and see what happens :)

(In Python3, I understand that is what callable() will do. Let's hope
that the function called has no side-effects.)

I also didn't mention classmethods, staticmethods or functions assigned
to attributes. As Ton van Vliet is a beginner, I didn't think he needed
to be flooded with too many complications all at once. It's quite
possible to program in Python for years and never come across a callable
attribute that isn't an ordinary method.

Also, I wasn't actually thinking about testing for methods before calling
them. Given the context, I was thinking more about manual experimentation
at the interpreter. Perhaps I should have said.

--
Steven.
Nov 28 '07 #84
Steven D'Aprano a écrit :
On Tue, 27 Nov 2007 10:11:48 +0100, Bruno Desthuilliers wrote:
>Fine. Now since Python let you define your own callable types and your
own descriptors, you can as well have an attribute that behave just like
a method without being an instance of any of the method types - so the
above test defeats duck typing. And since you can have callable
attributes that are definitively not methods, you can't rely on the fact
that an attribute is callable neither.

I did say the usual way was to call it and see what happens :)
It's certainly *not* "the usual way" to test if some object is callable
- it's only ok if you really intented to call it, and even then it might
be better to test before calling so you distinguish exceptions raised
from within the called code from exceptions due the the call itself.
(In Python3, I understand that is what callable() will do.
IIRC, there's no callable() function at all in Python 3.
>
I also didn't mention classmethods, staticmethods or functions assigned
to attributes. As Ton van Vliet is a beginner, I didn't think he needed
to be flooded with too many complications all at once.
Understanding the object model of a (mostly) OO langage is not what I'd
call "too many complications". But I may be a bit biased !-)
It's quite
possible to program in Python for years and never come across a callable
attribute that isn't an ordinary method.
You loose !-)

callable(object .__class__)
=True
Nov 28 '07 #85

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.