473,890 Members | 1,394 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 7265
Bruno Desthuilliers wrote:
[snip]>
Too bad : in Python, everything's an object, so 'methods' are attributes
too.
What do you see as a problem here?
Surely it gives useful flexibility.

Colin W.

Nov 26 '07 #71
On Mon, 26 Nov 2007 21:48:36 +0100, Ton van Vliet wrote:
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 ;-)
All methods are attributes. Not all attributes are methods. The usual way
to see if something is a method is to try calling it and see what
happens, but if you want a less informal test, try type():

>>type(''.joi n)
<type 'builtin_functi on_or_method'>
>>type(Foo().fo o) # with the obvious definition of Foo
<type 'instancemethod '>


--
Steven
Nov 27 '07 #72
Steven D'Aprano a écrit :
On Mon, 26 Nov 2007 21:48:36 +0100, Ton van Vliet wrote:
>On Mon, 26 Nov 2007 20:14:50 +0100, Bruno Desthuilliers
<bd*********** ******@free.que lquepart.frwrot e:
>>>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
Yes : reading the doc. But that's something the compiler will have hard
time doing.
>(I'm
just a beginner ;-)

All methods are attributes. Not all attributes are methods. The usual way
to see if something is a method is to try calling it and see what
happens, but if you want a less informal test, try type():

>>>type(''.join )
<type 'builtin_functi on_or_method'>
>>>type(Foo().f oo) # with the obvious definition of Foo
<type 'instancemethod '>

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.


Nov 27 '07 #73
In article <47************ ***********@new s.free.fr>,
Bruno Desthuilliers <br************ ********@wtf.we bsiteburo.oops. com>
wrote:
Steven D'Aprano a écrit :
On Mon, 26 Nov 2007 21:48:36 +0100, Ton van Vliet wrote:
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

Yes : reading the doc. But that's something the compiler will have hard
time doing.
(I'm
just a beginner ;-)
All methods are attributes. Not all attributes are methods. The usual way
to see if something is a method is to try calling it and see what
happens, but if you want a less informal test, try type():

>>type(''.joi n)
<type 'builtin_functi on_or_method'>
>>type(Foo().fo o) # with the obvious definition of Foo
<type 'instancemethod '>


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.
If you want to have a little fun:

class peverse:
def __call__(self):
raise AttributeError ("peverse instance has no __call__ method")

x = peverse()
x()
Nov 27 '07 #74
On Nov 27, 3:20 am, Roy Smith <r...@panix.com wrote:
If you want to have a little fun:

class peverse:
def __call__(self):
raise AttributeError ("peverse instance has no __call__ method")

x = peverse()
x()
That is "peverse", but still...

from types import FunctionType
type(x) == FunctionType # False

And you can't (easily?) subclass FunctionType:

Error when calling the metaclass bases
type 'function' is not an acceptable base type

;)

Regards,
Jordan
Nov 27 '07 #75
Colin J. Williams a crit :
Bruno Desthuilliers wrote:
[snip]>
>Too bad : in Python, everything's an object, so 'methods' are
attributes too.

What do you see as a problem here?
You snipped too much... Tony wrote "However, I was more thinking in
terms of attributes only" (implying: attributes != methods). So the "too
bad" meant "won't work here".
Surely it gives useful flexibility.
Indeed. But that's not the problem here.
Nov 27 '07 #76
MonkeeSage a crit :
On Nov 27, 3:20 am, Roy Smith <r...@panix.com wrote:
>If you want to have a little fun:

class peverse:
def __call__(self):
raise AttributeError ("peverse instance has no __call__ method")

x = peverse()
x()
print callable(x)
=True
That is "peverse", but still...

from types import FunctionType
type(x) == FunctionType # False

And you can't (easily?) subclass FunctionType:

Error when calling the metaclass bases
type 'function' is not an acceptable base type

;)
You don't have to subclass function to define a callable type that
implements the descriptor protocol so it behaves just like a function in
the context of an attribute lookup.
Nov 27 '07 #77
On Nov 27, 4:22 am, Bruno Desthuilliers
You don't have to subclass function to define a callable type that
implements the descriptor protocol so it behaves just like a function in
the context of an attribute lookup.
I'm aware, and I understand that python's types (as with other duck-
typed languages) are basically just an object's capabilities; I was
just pointing out that, if needed (though I can't think of why
offhand...mabye some kind of sandbox?), you can detect built-in
functions. Hmm...but then again, it seems that shadowing a built-in
function still reports as it's type as FunctionType...

In [1]: from types import FunctionType

In [2]: def len(x):
...: # mischief
...: pass
...:

In [3]: type(len) == FunctionType
Out[3]: True

Regards,
Jordan
Nov 27 '07 #78
On Nov 27, 9:20 am, Roy Smith <r...@panix.com wrote:
In article <474bdf4f$0$192 26$426a7...@new s.free.fr>,
Bruno Desthuilliers <bruno.42.desth uilli...@wtf.we bsiteburo.oops. com>

wrote:
Steven D'Aprano a crit :
On Mon, 26 Nov 2007 21:48:36 +0100, Ton van Vliet wrote:
>On Mon, 26 Nov 2007 20:14:50 +0100, Bruno Desthuilliers
><bdesth.quelqu ech...@free.que lquepart.frwrot e:
>>>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
Yes : reading the doc. But that's something the compiler will have hard
time doing.
>(I'm
>just a beginner ;-)
All methods are attributes. Not all attributes are methods. The usual way
to see if something is a method is to try calling it and see what
happens, but if you want a less informal test, try type():
>>>type(''.join )
<type 'builtin_functi on_or_method'>
>>>type(Foo().f oo) # with the obvious definition of Foo
<type 'instancemethod '>
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.

If you want to have a little fun:

class peverse:
def __call__(self):
raise AttributeError ("peverse instance has no __call__ method")

x = peverse()
x()

Horrific cluge:
--

def noself(func):
def t(*args, **kwargs):
self = args[0]
g = globals()
delete = []
for varname in dir(self):
if not varname.startsw ith("__") and varname not in g:
g[varname] = self.__getattri bute__(varname)
delete.append(v arname)
func(*args, **kwargs)
for varname in delete:
del(g[varname])
return t
class Test(object):
x = 1

@noself
def test(self):
print x

>>foo = Test()
foo.test()
1

--

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)

Iain
Nov 27 '07 #79
MonkeeSage a crit :
On Nov 27, 4:22 am, Bruno Desthuilliers
>You don't have to subclass function to define a callable type that
implements the descriptor protocol so it behaves just like a function in
the context of an attribute lookup.

I'm aware, and I understand that python's types (as with other duck-
typed languages) are basically just an object's capabilities; I was
just pointing out that, if needed (though I can't think of why
offhand...mabye some kind of sandbox?), you can detect built-in
functions.
Ok.
Hmm...but then again, it seems that shadowing a built-in
function still reports as it's type as FunctionType...
Of course (at least as long as you sahdow it with another function) -
Why would it be otherwise ?

Nov 27 '07 #80

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.