"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 "e
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
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
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.
--
http://mail
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', a
>>> 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 nake
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 compr
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 t
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 e
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)
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-
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
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
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, it
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 t
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
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 "(s
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
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
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 pr
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 ten
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
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 argu
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 (exp
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
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 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.
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 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
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 migh
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 les
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 a
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
> 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 the
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
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
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 migh
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
>
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 pro
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 rea
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, 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
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. ;)
--
Gra
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 harde
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
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 for
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.
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
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 ne
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 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 rece
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
>
> 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 avo
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
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 (lik
> 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,
56 matches
Mail list logo
