newbie: self.member syntax seems /really/ annoying - Python

Thanks guys -- yeah these two stategies (short s.varname; and explicit
rescoping, a=self.a etc) are more or less what I was using. That's
still kind of annoying though.

The s.varname approach still makes numerical code much harder to read.

I had a nasty bug with the boilerplate approach when forgetting to
reassign some of the variables back to members (self.a=a). And that's
a lot of boilerplate you need -- I thought the python way was to
minimize redundant code? (Ditching header files and curley brackets
was a main reason for me coming here).

I see the argument for making self explicit -- what would be wrong
with just .a instead of self.a though? That's still explicit but much
easier to read. (I think I've seen that somewhere else, is it C#?)

Charles Fox wrote:
> Thanks guys -- yeah these two stategies (short s.varname; and explicit
> rescoping, a=self.a etc) are more or less what I was using. That's
> still kind of annoying though.
>
> The s.varname approach still makes numerical code much harder to read.
>
> I had a nasty bug with the boilerplate approach when forgetting to
> reassign some of the variables back to members (self.a=a). And that's
> a lot of boilerplate you need -- I thought the python way was to
> minimize redundant code? (Ditching header files and curley brackets
> was a main reason for me coming here).
>
> I see the argument for making self explicit -- what would be wrong
> with just .a instead of self.a though? That's still explicit but much
> easier to read. (I think I've seen that somewhere else, is it C#?)

Charles, while you are quite right to air your ideas, do bear in mind
that this issue has been thrashed out again and again on this group
and in other forums. I hope you have at least read the FAQ:

http://www.python.org/doc/faq/genera...ions-and-calls

and PEP 3099:

http://www.python.org/dev/peps/pep-3099/

If you take the trouble to search the archives of this list alone
for, say, explicit+self, you'll see that there are quite strong arguments
(and argumentors) on both sides. In that sort of situation the status quo
tends to hold sway. (And in this case, GvR has only recently responded to
similar comments by Bruce Eckels -- a couple of heavyweights -- in a way
which makes it unlikely that this is going to change).

I think it's one of those things which comes down, fairly enough, to: we
do things this way and it works for us; other languages do other things
and it works for them.

TJG

On Sep 12, 4:43 pm, Charles Fox <charles....> wrote:
> Thanks guys -- yeah these two stategies (short s.varname; and explicit
> rescoping, a=self.a etc) are more or less what I was using. That's
> still kind of annoying though.
>
> The s.varname approach still makes numerical code much harder to read.
>
> I had a nasty bug with the boilerplate approach when forgetting to
> reassign some of the variables back to members (self.a=a). And that's
> a lot of boilerplate you need -- I thought the python way was to
> minimize redundant code? (Ditching header files and curley brackets
> was a main reason for me coming here).

You still can play with dictionaries, for instance:

def __init__(self, a, b, c):
vars(self).update(locals())

correspond to

self.a = a
self.b = b
self.c = c

(and actually also to self.self =self).

> I see the argument for making self explicit -- what would be wrong
> with just .a instead of self.a though? That's still explicit but much
> easier to read. (I think I've seen that somewhere else, is it C#?)

This has been proposed many times. But self is handy because you can
give
a different name to it: for instance it becomes cls when you are
inside a classmethod.


Michele Simionato

On 2007-09-12, Tim Golden <mail@timgolden.me.uk> wrote:

> I think it's one of those things which comes down, fairly
> enough, to: we do things this way and it works for us; other
> languages do other things and it works for them.

But not as nearly well as our way works for us, of course.

--
Grant Edwards grante Yow! I'm meditating on
at the FORMALDEHYDE and the
visi.com ASBESTOS leaking into my
PERSONAL SPACE!!

On Wed, Sep 12, 2007 at 07:43:51AM -0700, Charles Fox wrote regarding Re: newbie: self.member syntax seems /really/ annoying:
>
> Thanks guys -- yeah these two stategies (short s.varname; and explicit
> rescoping, a=self.a etc) are more or less what I was using. That's
> still kind of annoying though.
>
> The s.varname approach still makes numerical code much harder to read.
>

For what it's worth, if you stick with python for a while, you will stop noticing the self, and be able to see what you're looking for quite clearly.

Moreso if you use s.

Cheers,
Cliff

Charles Fox wrote:
> I've just started playing around with Python, as a possible
> replacement for a mix of C++, Matlab and Lisp. The language looks
> lovely and clean with one huge exception: I do a lot of numerical
> modeling, so I deal with objects (like neurons) described
> mathematically in papers, by equations like
> a_dot = -k(a-u)
> In other languages, this translates nicely into code, but as far as I
> can tell, Python needs the ugly:
> self.a_dot = -self.k(self.a-self.u)
> For large equations this is going to make my code seriously unreadable
> to the point of needing to switch back to Matlab -- and it seems to go
> against everything else about python's simplicity and elegance. Am I
> missing something? Is there something like a 'with' command that lets
> me set the scope, like
>
> with self:
> .a_dot = -.k(.a-.u)
>
> It's premature to make language suggestions as I am new to the
> language, but I would have though that making a 'with self' explicit
> in all methods would have been neat, so I could just write
> .a_dot = -.k(.a-.u)
> which would still avoid confusion with local function variables, since
> '.a' is different from 'a'.
>
> Please help if I am missing something -- this looks like a great
> language but I am going to mad trying to read numerical code full of
> 'self.'s breaking up the equations.

I don't know if it'll help or not, but you might try using matplotlib,
numpy or pymat. One of those may make it easier to do your
calculations.

Mike

On 9/12/07, Charles Fox <charles.fox> wrote:
> Thanks guys -- yeah these two stategies (short s.varname; and explicit
> rescoping, a=self.a etc) are more or less what I was using. That's
> still kind of annoying though.
>
> The s.varname approach still makes numerical code much harder to read.
>
> I had a nasty bug with the boilerplate approach when forgetting to
> reassign some of the variables back to members (self.a=a). And that's
> a lot of boilerplate you need -- I thought the python way was to
> minimize redundant code? (Ditching header files and curley brackets
> was a main reason for me coming here).
>
> I see the argument for making self explicit -- what would be wrong
> with just .a instead of self.a though? That's still explicit but much
> easier to read. (I think I've seen that somewhere else, is it C#?)
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>


This is terrible and horrible, please don't use it. That said,
presenting the magic implicit_self context manager!

from __future__ import with_statement
import sys

class implicit_self(object):
def __init__(self, obj):
self.obj = obj
def __enter__(self):
local = sys._getframe(1).f_locals
local.update(self.obj.__dict__)
def __exit__(self, exc, obj, tb):
local = sys._getframe(1).f_locals
for k in self.obj.__dict__:
setattr(self.obj, k, local[k])

if __name__ == '__main__':
class Test(object):
pass
t = Test()
t.a = 10
t.b = 20
with implicit_self(t):
print a
print b
a = 40
b = a * 2

print t.a
print t.b

On 2007-09-12, Michele Simionato <michele.simionato> wrote:
>> I see the argument for making self explicit -- what would be
>> wrong with just .a instead of self.a though? That's still
>> explicit but much easier to read. (I think I've seen that
>> somewhere else, is it C#?)
>
> This has been proposed many times. But self is handy because
> you can give a different name to it: for instance it becomes
> cls when you are inside a classmethod.

The treatment of self in the function's parameter list seems to
be the pitfall of any .member shortcut proposal. Most proposals
don't even address that point.

Does it become:

class Foo:
def __init__():
.bar = 40

or

class Foo:
def __init__(.):
.bar = 40

or

class Foo:
def __init__(self):
.bar = 40

I guess the middle one is the most consistent, but it seems
ugly compared to what we have now.

--
Neil Cerutti

Chris Mellon <arkanes> wrote:
...
> This is terrible and horrible, please don't use it. That said,
> presenting the magic implicit_self context manager!

....which doesn't work in functions -- just try changing your global
code:

> with implicit_self(t):
> print a
> print b
> a = 40
> b = a * 2

into a function and a call to it:

def f():
with implicit_self(t):
print a
print b
a = 40
b = a * 2
f()

....even with different values for the argument to _getframe. You just
can't "dynamically" add local variables to a function, beyond the set
the compiler has determined are local (and those are exactly the ones
that are *assigned to* in the function's body -- no less, no more --
where "assigned to" includes name-binding statements such as 'def' and
'class' in addition to plain assignment statements, of course).

Making, say, 'a' hiddenly mean 'x.a', within a function, requires a
decorator that suitably rewrites the function's bytecode... (after
which, it WOULD still be terrible and horrible and not to be used, just
as you say, but it might at least _work_;-). Main problem is, the
decorator needs to know the set of names to be "faked out" in this
terrible and horrible way at the time the 'def' statement executes: it
can't wait until runtime (to dynamically determine what's in var(self))
before it rewrites the bytecode (well, I guess you _could_ arrange a
complicated system to do that, but it _would_ be ridiculously slow).

You could try defeating the fundamental optimization that stands in your
way by adding, say,
exec 'pass'
inside the function-needing-fakeouts -- but we're getting deeper and
deeper into the mire...;-)


Alex