BJörn Lindqvist wrote:
On 9/12/07, Dave Hansen [EMAIL PROTECTED] wrote:
The name self is just a convention. You can give it any name you
wish. Using s is common.
Not it's not common. And the name self is a convention codified in
PEP8 which you shouldn't violate.
And I agree with the OP
Colin J. Williams [EMAIL PROTECTED] writes:
.rect.width = .foo(.rect.x + .rect.y) * .boo()
Does this preceding . create parsing problems?
Perhaps not for the computer, but certainly for the human. A leading
. is far too easy to miss when visually scanning the code, and fails
the explicit
Wildemar Wildenburger wrote:
stef mientki wrote:
Wildemar Wildenburger wrote:
Bruno Desthuilliers wrote:
OTHO, simple math-illeterate programmers like me will have hard
time maintaining such a code.
Certainly, but again: Such main people are not the intended
audience. The code is
stef mientki wrote:
Indeed, so I wondered why there isn't open source alternative (at
least I didn't find one).
Have a look at scilab and octave. Not sure if it's GPL though.
Regards,
Björn
--
BOFH excuse #387:
Your computer's union contract is set to expire at midnight.
--
On Sep 12, 6:21 am, Charles Fox [EMAIL PROTECTED] 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
Why not use '_' as the self variable. It is minimal and achieves
close to '.var', as '_.var' isn't that different. I know its a little
perl-esque, but its not a bad convention if you are aiming to up
readability of your code.
class test:
def __init__(self):
_ = self;
_.a = 0;
On Thu, 13 Sep 2007 12:10:03 +, [EMAIL PROTECTED] wrote:
Why not use '_' as the self variable. It is minimal and achieves close
to '.var', as '_.var' isn't that different. I know its a little
perl-esque, but its not a bad convention if you are aiming to up
readability of your code.
I
Steven D'Aprano wrote:
On Thu, 13 Sep 2007 12:10:03 +, [EMAIL PROTECTED] wrote:
Why not use '_' as the self variable. It is minimal and achieves close
to '.var', as '_.var' isn't that different. I know its a little
perl-esque, but its not a bad convention if you are aiming to up
On 9/12/07, Dave Hansen [EMAIL PROTECTED] wrote:
The name self is just a convention. You can give it any name you
wish. Using s is common.
Not it's not common. And the name self is a convention codified in
PEP8 which you shouldn't violate.
And I agree with the OP that the convention is
On 9/13/07, Wildemar Wildenburger [EMAIL PROTECTED] wrote:
because I'm trained to interpret the underscore as a synonym for one
space. It's not particularly beautiful, but that is probably a matter of
habituation. And that exact word is probably the reason why I'd still
use self or s
On Sep 12, 10:05 am, [EMAIL PROTECTED] (Alex Martelli) wrote:
...
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
On Thu, 13 Sep 2007 16:30:36 +0200, BJörn Lindqvist
wrote:
And I agree with the OP that the convention is really annoying.
self.rect.width = self.foo(self.rect.x + self.rect.y) * self.boo()
is much less concise than
s.rect.width = s.foo(s.rect.x + s.rect.y) * s.boo()
Y do u thnk
hmm, I guess this is the difference between numerical programming and
the rest -- sure, if I was writing a database server or something it
would be great to have thisObject.veryLongName to know what everything
is -- however when you are implementing a model from a published
paper, the variables
On Thu, 13 Sep 2007 16:16:03 +0200, Wildemar Wildenburger wrote:
I see merit in using
(_.foo + _.bar) * _.baz
instead of
(s.foo + s.bar) * s.baz
because I'm trained to interpret the underscore as a synonym for one
space. It's not particularly beautiful, but that is probably a
Charles Fox wrote:
Maybe for now I will just fix up my emacs to display the world 'self'
in 10% gray... :-)
Now *that* is a clever idea! (And that's no irony.)
/W
--
http://mail.python.org/mailman/listinfo/python-list
Eduardo O. Padoan wrote:
On 9/13/07, Wildemar Wildenburger [EMAIL PROTECTED] wrote:
because I'm trained to interpret the underscore as a synonym for one
space. It's not particularly beautiful, but that is probably a matter of
habituation. And that exact word is probably the reason why I'd
On Thu, Sep 13, 2007 at 04:21:36PM -, Steven D'Aprano wrote regarding Re:
newbie: self.member syntax seems /really/ annoying:
It's not just a matter of taste.
Reading comprehensibility is an objective, measurable quantity, and I
would bet that (self.foo + self.bar) * self.baz would
Steven D'Aprano wrote:
And I agree with the OP that the convention is really annoying.
self.rect.width = self.foo(self.rect.x + self.rect.y) * self.boo()
is much less concise than
s.rect.width = s.foo(s.rect.x + s.rect.y) * s.boo()
Y do u thnk bng cncis is lwys a gd thng?
On Thu, 2007-09-13 at 09:05 -0700, Charles Fox wrote:
when you are implementing a model from a published
paper, the variables tend to be single greek or roman letter names,
possibly with subscripts and superscripts, and it helps if the name
you see on the screen is the same as the name on the
OKB (not okblacke) wrote:
What kind of name is this?
No, but the point being made is that it would be better IN
THIS CASE.
It wouldn't. IMHO, rewriting the code to two or three lines would be
better. No need to scream, BTW.
Regards,
Björn
--
BOFH excuse #447:
According to Microsoft,
Bjoern Schliessmann wrote:
No, but the point being made is that it would be better IN
THIS CASE.
It wouldn't. IMHO, rewriting the code to two or three lines would be
better.
Well I think Charles' Point about making the equations look like the
ones in the paper(s) is a pretty good one.
Wildemar Wildenburger a écrit :
Bjoern Schliessmann wrote:
No, but the point being made is that it would be better IN
THIS CASE.
It wouldn't. IMHO, rewriting the code to two or three lines would be
better.
Well I think Charles' Point about making the equations look like the
ones in
On Sep 13, 9:55 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Thu, 13 Sep 2007 12:10:03 +, [EMAIL PROTECTED] wrote:
Why not use '_' as the self variable. It is minimal and achieves close
to '.var', as '_.var' isn't that different. I know its a little
perl-esque,
Bruno Desthuilliers wrote:
OTHO, simple math-illeterate programmers like me will have hard time
maintaining such a code.
Certainly, but again: Such main people are not the intended audience.
The code is for people that know how to read these equations. I think a
general rule of (any form of)
Wildemar Wildenburger wrote:
Bruno Desthuilliers wrote:
OTHO, simple math-illeterate programmers like me will have hard time
maintaining such a code.
Certainly, but again: Such main people are not the intended audience.
The code is for people that know how to read these equations.
stef mientki wrote:
Wildemar Wildenburger wrote:
Bruno Desthuilliers wrote:
OTHO, simple math-illeterate programmers like me will have hard time
maintaining such a code.
Certainly, but again: Such main people are not the intended audience.
The code is for people that know how to
On Thu, 13 Sep 2007 13:14:25 -0400, J. Clifford Dyer wrote:
On Thu, Sep 13, 2007 at 04:21:36PM -, Steven D'Aprano wrote
regarding Re: newbie: self.member syntax seems /really/ annoying:
It's not just a matter of taste.
Reading comprehensibility is an objective, measurable quantity
Certainly, but again: Such main people are not the intended audience.
The code is for people that know how to read these equations. I think
a general rule of (any form of) writing is to write with your audience
in mind. I always do that and happily, that audience is usually naked.
On Thu, 13 Sep 2007 12:47:27 -0700, Carl Banks wrote:
On Sep 13, 9:55 am, Steven D'Aprano [EMAIL PROTECTED]
cybersource.com.au wrote:
On Thu, 13 Sep 2007 12:10:03 +, [EMAIL PROTECTED] wrote:
Why not use '_' as the self variable. It is minimal and achieves
close to '.var', as '_.var'
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.
You could try this in your functions:
s = self
Then you can use code like this: s.a_dot = s.k(s.a-s.u)
Another option, if
On Sep 12, 12:21 pm, Charles Fox [EMAIL PROTECTED] 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
On 9/12/07, David [EMAIL PROTECTED] wrote:
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.
You could try this in your functions:
s = self
Then you can use code 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
Charles Fox a écrit :
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
On Behalf Of Charles Fox
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)
In addition to the other advice you've received,
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
On Wed, 12 Sep 2007 03:21:58 -0700, 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
On Sep 12, 5:21 am, Charles Fox [EMAIL PROTECTED] 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
Dave Hansen a écrit :
(snip)
As others have mentioned, you can also provide local synonyms if the
dot syntax is too onerous. But make sure you use the member access
syntax if the result of an expression is an immutable type. For
example, I assume a_dot is a mutable type, such as a list. If
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
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
On Sep 12, 4:43 pm, Charles Fox [EMAIL PROTECTED] 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
On 2007-09-12, Tim Golden [EMAIL PROTECTED] 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
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
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
On 9/12/07, Charles Fox [EMAIL PROTECTED] 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
On 2007-09-12, Michele Simionato [EMAIL PROTECTED] 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
Chris Mellon [EMAIL PROTECTED] 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
On Sep 12, 1:05 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
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
On Sep 12, 4:52 pm, Carl Banks [EMAIL PROTECTED] wrote:
(The loops would necessarily be unwrapped in the actual
bytecode.)
And by unwrapped, I mean unrolled.
:E3
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
As a newbie to Python (and OOP), I would love to hear what people
think of Steven's suggestion below. Is there a reason why classes
would be useful for the OP's question ? If you can point me to a brief
online tutorial addressing this, I would happily go there to read it
too :)
Thanks, Suresh
On Behalf Of madzientist
As a newbie to Python (and OOP), I would love to hear what
people think of Steven's suggestion below. Is there a reason
why classes would be useful for the OP's question ? If you
can point me to a brief online tutorial addressing this, I
would happily go there to
Carl Banks [EMAIL PROTECTED] wrote:
...
How about this? The decorator could generate a bytecode wrapper that
would have the following behavior, where __setlocal__ and
__execute_function__ are special forms that are not possible in
Python. (The loops would necessarily be unwrapped in the
On Sep 12, 7:23 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
Carl Banks [EMAIL PROTECTED] wrote:
...
How about this? The decorator could generate a bytecode wrapper that
would have the following behavior, where __setlocal__ and
__execute_function__ are special forms that are not
J. Clifford Dyer wrote:
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
On Sep 12, 1:05 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
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
56 matches
Mail list logo
