Re: newbie: self.member syntax seems /really/ annoying
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 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() Yes, but the OP went a step further, he suggested: .rect.width = .foo(.rect.x + .rect.y) * .boo() Among the many responses, I didn't spot anyone who dealt with this issue. Does this preceding . create parsing problems? Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 principle. -- \I have the simplest tastes. I am always satisfied with the | `\best. -- Oscar Wilde | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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. Wouldn't Mathematica, Maple or MathCad be a far better choice ? Well, those cost money ... Maxima doesn't cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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. Just an idea: I think that if you have to get a more readable code you could abstract the function from the object using a significative name and then use this named function passing **self.__dict__ For example in your module you could write: #-- functional section --- def dothis(k,a,u): return k*(a-u) def dothat(m,r,k): return m*r+(k.m)^m #- Class definition -- class Bar(object): def foo(self): self.a_dot = dothis(**self.__dict__) self.boo = dothat(**self.__dict__) In this way the functional part is pure expression and very readable. HTH G. -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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; _.u = 0; _.a_dot = 0; def k(self, val): return val**2; #not sure what k does def getA_Dot(self): _ = self; _.a_dot = _.k(_.a-_.u); -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 think the definitions of up or readability you are using are very different from mine. To me, to up something means to increase it, and readability means the ease of comprehension when reading something. You seem to be using the opposite definition for one or the other. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 readability of your code. I think the definitions of up or readability you are using are very different from mine. To me, to up something means to increase it, and readability means the ease of comprehension when reading something. You seem to be using the opposite definition for one or the other. OK, making a pointless reply to pointless reply, but anyway: 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 matter of habituation. And that exact word is probably the reason why I'd still use self or s (explained by a comment, because I can get very dumb if I have to). It's a matter of taste, so there is no point in bashing a valid suggestion. /W (I am aware that I'm banging a philosophy on people's heads just as Steven did, so I'm no better, I know.) -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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() -- mvh Björn -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 (explained by a comment, because I can get very dumb if I have to). Have you worked with code using gettext functions imported as _? When I see a single underscore as a name, i18n comes to mind. -- http://www.advogato.org/person/eopadoan/ Bookmarks: http://del.icio.us/edcrypt -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 _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...;-) What about abusing 'import' like this: def f(): with implicit_self(t): sys.modules['__the_mire__'] = t from __the_mire__ import a, b print a print b a = 40 b = a * 2 If the list of attributes is long then 'import' can save some typing compared to a = self.a b = self.b ... z = self.z -- Regards, Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 bng cncis is lwys a gd thng? Being concise is not always a good thing. I notice that you separate terms with spaces, even when Python itself doesn't need them. You also are happy to use infix notation, which requires brackets, instead of a postfix or RPN language that doesn't. You also have attributes named rect and width instead of r and w: s.r.w=s.f(s.r.x+s.r.y)*s.b() There. See how much more readable that isn't? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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 paper, as is the case in matlab. You want the equation on screen to look as similar to the one on the paper as possible, especially if its going to be read by another programmer who is familiar with the paper. Maybe for now I will just fix up my emacs to display the world 'self' in 10% gray... :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 matter of habituation. And that exact word is probably the reason why I'd still use self or s (explained by a comment, because I can get very dumb if I have to). It's a matter of taste, so there is no point in bashing a valid suggestion. 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 be measurably more readable on average than either of your two alternatives _even for those people who claim to hate it_. But what do I care? If people are writing code that only they will see, they can use any conventions they feel like. It's no skin off my nose. But if you're writing code that is going to be seen by others in the wider community, perhaps because it's open source, or because you're working in a team of coders, or even because you're posting snippets to comp.lang.python asking for assistance, then it is wise to write using conventions that others use. The harder you make it for people to read your code, the fewer people will be willing or able or bothered to read it. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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
Re: newbie: self.member syntax seems /really/ annoying
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 still use self or s (explained by a comment, because I can get very dumb if I have to). Have you worked with code using gettext functions imported as _? When I see a single underscore as a name, i18n comes to mind. See? Habituation. Just what I'm saying. :) /W -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 be measurably more readable on average than either of your two alternatives _even for those people who claim to hate it_. It may be measurable, but it is also contextual. Depending on what you've been trained in, one way or the other might be more readable. For a teenager in a major city, tagging is far more readable than a Fraktur font, but for Mad King Ludwig, it was certainly quite the opposite. Objectively, measurably so, to be sure. Also depending on what you are looking for in the source code. Readability can in most cases be enhanced by minimizing those things that serve only to distract from the meaning. Hence the OP's desire to see his formulae, uncluttered by the word self. Now will such a change make his code less readable for other python programmers who may look at it later? Indubitably. But that's a different issue. Moreover, it may be that the best solution is to stop trying for an object-oriented solution. Why not use a functional programming style to represent mathematical functions? Cheers, Cliff -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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? No, but the point being made is that it would be better IN THIS CASE. -- --OKB (not okblacke) Brendan Barnwell Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail. --author unknown -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 paper, as is the case in matlab. You want the equation on screen to look as similar to the one on the paper as possible, especially if its going to be read by another programmer who is familiar with the paper. In that case, you could/should move the calculations into a function that uses local variables, instead of a method that uses instance attributes. Accessing local variables is faster than accessing instance attributes, and you get rid of the annoying self prefix. -- Carsten Haese http://informixdb.sourceforge.net -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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's by design -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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. That is a special case in that the code becomes clearer when it conformes to the standards of the domain it is referring to; it is not meant to be understood by itself but rather in conjunction with documents that motivate it. Or in short: Breaking it into n1 lines would make it more readable but would break the connection with the form given in the papers. (Yes, of course you can refer to the eq. in a comment but believe me: if you're used to seeing a certain (form of) equation, your mind will trip over any variation. That is best avoided.) ... my 2 sents, anyway ... /W -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 the paper(s) is a pretty good one. That is a special case in that the code becomes clearer when it conformes to the standards of the domain it is referring to; it is not meant to be understood by itself but rather in conjunction with documents that motivate it. Or in short: Breaking it into n1 lines would make it more readable but would break the connection with the form given in the papers. (Yes, of course you can refer to the eq. in a comment but believe me: if you're used to seeing a certain (form of) equation, your mind will trip over any variation. That is best avoided.) OTHO, simple math-illeterate programmers like me will have hard time maintaining such a code. Also and FWIW, it's not always possible to make a direct translation of a mathematic formula|algorithm in Python, and even when it is, it's not always the best thing to do wrt/ perfs (I recently had such a case, and after a pythonic rewrite the code was about 75% shorter, 50% faster, and 200% more readable for average joe programmer). ... my 2 sents, anyway ... May I add my 2 cents - or should I send them ?-) -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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, but its not a bad convention if you are aiming to up readability of your code. I think the definitions of up or readability you are using are very different from mine. To me, to up something means to increase it, and readability means the ease of comprehension when reading something. You seem to be using the opposite definition for one or the other. He's not. People who've never done a lot of numerical programming might have a hard time understanding this, but what is considered readable for ordinary programming is just does not apply when reading and writing pages of mathematical formulae. Trying to apply the ordinary standards of readability to numerical programming is like trying to write a mathematical treatise in English prose only, with no mathematical notation. It would be totally unreadable, almost as unreadable as a sociology textbook. In the same way, many pages of formulas would be unreadable using ordinary standards of readability (though not quite to the same degree). The most readable numerical code looks as much like the printed equations as possible. self. is a distraction; it's not in the original formula; it's boilerplate. It takes away from the readability of the code. Assuming that you can't get rid of the attribute syntax, minimizing the visual footprint of it will increase readability. So _. is more readable than self. because it changes the appearance of the printed formula a lot less. Having said all that, I would not use _., ever. I probably wouldn't even use Python if I had lots of numerical formulas to implement; I'd wrap up some C or Fortran code. If I did use Python I'd avoid implementing lots of formulas in class methods. If I had do this stuff in a method, and I only had a few formulas, I'd tolerate self. for the sake of conformance. If I had many fomulas, I would make local copies at the top. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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) writing is to write with your audience in mind. I always do that and happily, that audience is usually naked. Also and FWIW, it's not always possible to make a direct translation of a mathematic formula|algorithm in Python, and even when it is, it's not always the best thing to do wrt/ perfs (I recently had such a case, and after a pythonic rewrite the code was about 75% shorter, 50% faster, and 200% more readable for average joe programmer). Your point. Different game, but still your point. ;) ... my 2 sents, anyway ... May I add my 2 cents - or should I send them ?-) No, actually you're supposed to smell them. Oh, how I love homophones! /W -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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. 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. Wouldn't Mathematica, Maple or MathCad be a far better choice ? cheers, Stef Mientki -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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. Wouldn't Mathematica, Maple or MathCad be a far better choice ? Well, those cost money ... Hey, why am *I* arguing here at all? This isn't my thread! Well, I guess the scientist in me felt tickled. /W -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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, and I would bet that (self.foo + self.bar) * self.baz would be measurably more readable on average than either of your two alternatives _even for those people who claim to hate it_. It may be measurable, but it is also contextual. Depending on what you've been trained in, one way or the other might be more readable. For a teenager in a major city, tagging is far more readable than a Fraktur font, but for Mad King Ludwig, it was certainly quite the opposite. Cliff, we're discussing Python programming, not Java programming or assembly language programming or tagging trains. Let the damn taggers invent their own programming language and stop graffiti-ing Python. And speaking of readability... your post shows up in my news reader with each paragraph as a single, long, long LONG line scrolling about five full screens to the right. Please configure your software to follow the Usenet convention of putting newline characters at the end of each line, or every 72 (?) characters, whichever comes first. Moreover, it may be that the best solution is to stop trying for an object-oriented solution. Why not use a functional programming style to represent mathematical functions? Go back to the beginning of the thread, and you'll see that that's just what I suggested. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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. Wouldn't Mathematica, Maple or MathCad be a far better choice ? Well, those cost money ... Indeed, so I wondered why there isn't open source alternative (at least I didn't find one). some Latex derivate + wxPython + Python could do the job Hey, why am *I* arguing here at all? This isn't my thread! Well, I guess the scientist in me felt tickled. Well, i'm on the sideline too ;-) cheers, Stef -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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' 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 think the definitions of up or readability you are using are very different from mine. To me, to up something means to increase it, and readability means the ease of comprehension when reading something. You seem to be using the opposite definition for one or the other. He's not. People who've never done a lot of numerical programming might have a hard time understanding this, but what is considered readable for ordinary programming is just does not apply when reading and writing pages of mathematical formulae. Teaching your grandmother to suck eggs. I'm not a professional coder, but I'm not a stranger to numerical programming either. [snip] The most readable numerical code looks as much like the printed equations as possible. self. is a distraction; it's not in the original formula; it's boilerplate. It takes away from the readability of the code. Assuming that you can't get rid of the attribute syntax, Why would you assume that? Go back to the beginning of this thread, and you'll see that I suggested that the Original Poster stop forcing his maths functions into classes and put them in functions where they belong. As far as I'm concerned, this thread has clearly evolved to no longer be specifically about the OP's problem that classes don't read like maths functions (that's a solved problem -- don't use classes) and is now discussing the generic issue that some people don't have good taste when it comes to programming languages. -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
newbie: self.member syntax seems /really/ annoying
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 you use the vars a lot in a given function, is to copy them to local vars. This can also slightly speed up your code (fewer member lookups). -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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. You can always use aliases a = self.a u = self.u ... or even s = self or play games with dictionaries. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 this: s.a_dot = s.k(s.a-s.u) Another option, if you use the vars a lot in a given function, is to copy them to local vars. This can also slightly speed up your code (fewer member lookups). Also, there is no rule saying you need to use self, it's just a convention. You can declare your methods like this instead: def foo(s, arg1, arg2): s.a_dot = s.k(s.a-s.u) -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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. This is a FAQ - and the short answer is: no, you don't miss anything, and it's not going change. If you want, you can shorten the expressions like this: s = self s.a * s.b Or choose any other valid name, e.g. the underscore. Another (yet rather ugly) alternative would be to push the names into the global namespace. But that could of course create major mayhem! So take this with a huge grain of salt: globals().update(self.__dict__) a * b Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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) ugliness is a very subjective notion. As far as I'm concerned, I hate the m_myMember C++ convention, and have always used the 'this' (or whatever it's named) pointer/reference/pseudo-reference/whatever in languages where it's implicit - because I don't like such an important thing to be implicit. self.a_dot = - self.k(self.a - self.u) For large equations this is going to make my code seriously unreadable Ok, but this is another problem. 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? Yes. Is there something like a 'with' command that lets me set the scope, like with self: .a_dot = -.k(.a-.u) Nope. There's a 'with' statement, but it has nothing to do with this. The obvious solution to your problem is to make local references to the needed attributes at the start of your method, ie: def some_calc(self, whatever): k = self.k # yes, it works for methods too a = self.a u = self.u 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. The mandatory 'self' (FWIW, you can name it as you want, 'self' is just a convention) has long been the topic of lot of debates. While I do understand your motivations, there are actually good reasons for this design choice, but understanding these reasons requires some knowledge of Python's object model internals. As far as I'm concerned, I'm quite happy with the current design, but I don't do much maths !-) -- http://mail.python.org/mailman/listinfo/python-list
RE: newbie: self.member syntax seems /really/ annoying
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, if you don't need to preserve state, you could avoid the self business by putting your functions in a module instead of an object. def k(a): return a**3 def dot(a, u) return -k(a-u) Python modules are also objects, so they can serve in place of class instances much of the time. Regards, Ryan Ginstrom -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ 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 papers, by equations like I thought it was horrible when I started, but now when looking at somebody else's C++ code I find it very hard to work out whether something is a global, a member or a local variable, unless they use some sort of naming convention. If you alias self as s, it's only two more characters per variable access, which is the same as the C++ m_ naming convention. -- Jeremy Sanders http://www.jeremysanders.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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) I think you've been seriously mislead. You don't NEED self. That's only for writing classes. Although Python is completely object oriented, and everything is an object, you don't have to put your code in classes. Instead of doing something like this: class Adder(object): Pointless class to add things. def __init__(self, value): self.value = other def add(self, other): x = self.value + other return float(x) you don't need a class. Just write a function: def add(x, other): Function that adds other to x. return float(x + other) Here's how I would write your function above: def function(a, u, k): Calculate a_dot from a, u and k. return -k(a-u) And here is how I would use it: a = 57 # or whatever... u = 54 k = 3 a_dot = function(a, u, k) See? Not a single self in sight. You might also like to read about a strange, bizarre programming that forces you to put everything inside classes: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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 It goes back to the Zen of Python (import this): Explicit is better than implicit. And it's a boon to future maintainers of your code missing something? Is there something like a 'with' command that lets me set the scope, like with self: .a_dot = -.k(.a-.u) The name self is just a convention. You can give it any name you wish. Using s is common. 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 so, then you could simply use a_dot, k, a, u = self.a_dot, self.k, self.a, self.u a_dot = -k(a-u) However, if it's an immutable type, such as a scalar, strung, or tuple, you need self.a_dot = -k(a-u) And it gets trickier if you have members taking intermediate values... It's premature to make language suggestions as I am new to the That's for sure ;-) Regards, -=Dave -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 so, then you could simply use a_dot, k, a, u = self.a_dot, self.k, self.a, self.u a_dot = -k(a-u) However, if it's an immutable type, such as a scalar, strung, or tuple, you need self.a_dot = -k(a-u) Hmmm... Actually, whether self.a_dot is an instance of a mutable or immutable type won't change anything - in both case, it's only the *local* name a_dot that'll be rebound. So op as soon as you want to rebind (iow:assign to) an attribute, you *need* to use self.the_attr_name on the LHS. Of course, *mutating* is a different situation... -- http://mail.python.org/mailman/listinfo/python-list
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. 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
Re: newbie: self.member syntax seems /really/ annoying
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/general/#why-must-self-be-used-explicitly-in-method-definitions-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 -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 Edwards grante Yow! I'm meditating on at the FORMALDEHYDE and the visi.comASBESTOS leaking into my PERSONAL SPACE!! -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ 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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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). 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 actual bytecode.) for sym in sys._getframe(0).f_code.co_varnames: if sym == self: continue try: __setlocal__(sym,getattr(self,sym)) except AttributeError: pass try: __execute_function__() finally: for sym,val in locals.iteritems(): if sym == self: continue if sym in self: setattr(self,sym,val) This wouldn't be that much slower than just assigning local variables to locals by hand, and it would allow assignments in the straightforward way as well. There'd be some gotchas, so extra care is required, but it seems like for the OP's particular use case of a complex math calculation script, it would be a decent solution. I understand where the OP is coming from. I've done flight simulations in Java where there are lot of complex calculations using symbols. This is a typical formula (drag force calculation) that I would NOT want to have to use self.xxx for: FX_wind = -0.5 * rho * Vsq * Sref * (C_D_0 + C_D_alphasq*alpha*alpha + C_D_esq*e*e) Even if I'd habitually used this. in Java, I'd probably skip it in functions like htis. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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
Re: newbie: self.member syntax seems /really/ annoying
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 Sep 12, 8:38 am, Steven D'Aprano [EMAIL PROTECTED] cybersource.com.au wrote: 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 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) I think you've been seriously mislead. You don't NEED self. That's only for writing classes. Although Python is completely object oriented, and everything is an object, you don't have to put your code in classes. Instead of doing something like this: class Adder(object): Pointless class to add things. def __init__(self, value): self.value = other def add(self, other): x = self.value + other return float(x) you don't need a class. Just write a function: def add(x, other): Function that adds other to x. return float(x + other) Here's how I would write your function above: def function(a, u, k): Calculate a_dot from a, u and k. return -k(a-u) And here is how I would use it: a = 57 # or whatever... u = 54 k = 3 a_dot = function(a, u, k) See? Not a single self in sight. You might also like to read about a strange, bizarre programming that forces you to put everything inside classes: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns... -- Steven. -- http://mail.python.org/mailman/listinfo/python-list
RE: newbie: self.member syntax seems /really/ annoying
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 read it too :) In general, you should use classes when you need to maintain state. The classic example is a BankAccount class, each instance of which maintains a balance state. When you don't need to maintain state, module-level functions are fine. In fact, for testability/reliability, they're preferred, because when a method twiddles some internal state, it's much harder to test. It's valuable to have a function that always gives output x for input y, with no side effects. That (to me) is the appeal of the functional programming style. Regards, Ryan Ginstrom -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 actual bytecode.) I'm not entirely sure how you think those special forms would work. Right now, say, if the compiler sees somewhere in your function z = 23 print z it thereby knows that z is a local name, so it adds a slot to the function's locals-array, suppose it's the 11th slot, and generates bytecode for LOAD_FAST 11 and STORE_FAST 11 to access and bind that 'z'. (The string 'z' is stored in f.func_code.co_varnames but is not used for the access or storing, just for debug/reporting purposes; the access and storing are very fast because they need no lookup). If instead it sees a print z with no assignment to name z anywhere in the function's body, it generates instead bytecode LOAD_GLOBAL `z` (where the string `z` is actually stored in f.func_code.co_names). The string (variable name) gets looked up in dict f.func_globals each and every time that variable is accessed or bound/rebound. If the compiler turns this key optimization off (because it sees an exec statement anywhere in the function, currently), then the bytecode it generates (for variables it can't be sure are local, but can't be sure otherwise either as they MIGHT be assigned in that exec...) is different again -- it's LOAD_NAME (which is like LOAD_GLOBAL in that it does need to look up the variable name string, but often even slower because it needs to look it up in the locals and then also in the globals if not currently found among the locals -- so it may often have to pay for two lookups, not just one). So it would appear that to make __setlocal__ work, among other minor revolutions to Python's code objects (many things that are currently tuples, built once and for all by the compiler at def time, would have to become lists so that __setlocal__ can change them on the fly), all the LOAD_GLOBAL occurrences would have to become LOAD_NAME instead (so, all references to globals would slow down, just as they're slowed down today when the compiler sees an exec statement in the function body). Incidentally, Python 3.0 is moving the OTHER way, giving up the chore of dropping optimization to support 'exec' -- the latter will become a function instead of a statement and the compiler will NOT get out of its way to make it work right any more; if LOAD_NAME remains among Python bytecodes (e.g. it may remain in use for class-statement bodies) it won't be easy to ask the compiler to emit it instead of LOAD_GLOBAL (the trick of just adding exec 'pass' will not work any more;-). So, rewriting the bytecode on the fly (to use LOAD_NAME instead of LOAD_GLOBAL, despite the performance hit) seems to be necessary; if you're willing to take those two performance hits (at decoration time, and again each time the function is called) I think you could develop the necessary bytecode hacks even today. This wouldn't be that much slower than just assigning local variables to locals by hand, and it would allow assignments in the straightforward way as well. The big performance hit comes from the compiler having no clue about what you're doing (exactly the crucial hint that assigning local variables by hand DOES give the compiler;-) There'd be some gotchas, so extra care is required, but it seems like for the OP's particular use case of a complex math calculation script, it would be a decent solution. Making such complex calculations even slower doesn't look great to me. I understand where the OP is coming from. I've done flight simulations in Java where there are lot of complex calculations using symbols. This is a typical formula (drag force calculation) that I would NOT want to have to use self.xxx for: FX_wind = -0.5 * rho * Vsq * Sref * (C_D_0 + C_D_alphasq*alpha*alpha + C_D_esq*e*e) If ALL the names in every formula always refer to nothing but instance variables (no references to globals or builtins such as sin, pi, len, abs, and so on, by barenames) then there might be better tricks, ones that rely on that knowledge to actually make things *faster*, not slower. But they'd admittedly require a lot more work (basically a separate specialized compiler to generate bytecode for these cases). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 possible in Python. (The loops would necessarily be unwrapped in the actual bytecode.) I'm not entirely sure how you think those special forms would work. Right now, say, if the compiler sees somewhere in your function z = 23 print z it thereby knows that z is a local name, so it adds a slot to the function's locals-array, suppose it's the 11th slot, and generates bytecode for LOAD_FAST 11 and STORE_FAST 11 to access and bind that 'z'. (The string 'z' is stored in f.func_code.co_varnames but is not used for the access or storing, just for debug/reporting purposes; the access and storing are very fast because they need no lookup). If instead it sees a print z with no assignment to name z anywhere in the function's body, it generates instead bytecode LOAD_GLOBAL `z` (where the string `z` is actually stored in f.func_code.co_names). The string (variable name) gets looked up in dict f.func_globals each and every time that variable is accessed or bound/rebound. Withdrawn. For some reason it was in my mind that variables not bound within in the function would be local. :| [snip] This wouldn't be that much slower than just assigning local variables to locals by hand, and it would allow assignments in the straightforward way as well. The big performance hit comes from the compiler having no clue about what you're doing (exactly the crucial hint that assigning local variables by hand DOES give the compiler;-) Right. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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. Not sure that's true, since it still appears to bug Bruce Eckel ... regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden --- Asciimercial -- Get on the web: Blog, lens and tag the Internet Many services currently offer free registration --- Thank You for Reading - -- http://mail.python.org/mailman/listinfo/python-list
Re: newbie: self.member syntax seems /really/ annoying
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 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
All right Alex, and since I had 20 minutes of spare
time I implemented the decorator you are talking about by
using the wonderful byteplay module ;) Here it is:
import dis
from byteplay import Code, LOAD_GLOBAL, LOAD_ATTR, LOAD_FAST,
STORE_FAST
def instance2local(varname):
yield LOAD_FAST, 'self'
yield LOAD_ATTR, varname
yield STORE_FAST, varname
def declare_instance_vars(*varnames):
def dec(f):
c = Code.from_code(f.func_code)
# change LOAD_GLOBAL - LOAD_FAST
for i, (opcode, value) in enumerate(c.code):
if opcode == LOAD_GLOBAL and value in varnames:
c.code[i] = (LOAD_FAST, value)
# insert instance2local assigments at the beginning
assignments = []
for varname in varnames:
for pair in instance2local(varname):
assignments.append(pair)
c.code[0:0] = assignments
# redefine the code object
f.func_code = c.to_code()
return f
return dec
class Test(object):
def __init__(self):
self.a = 1
self.b = 2
def test1(self):
a = self.a
b = self.b
return a * b
@declare_instance_vars('a', 'b')
def test2(self):
return a * b
co1 = Test.__dict__['test1'].func_code
co2 = Test.__dict__['test2'].func_code
print 'bytecode for test1'
dis.dis(co1)
print 'bytecode for test2'
dis.dis(co2)
t = Test()
assert t.test1() == t.test2()
It is still a hack, since one is not supposed to mess around
with bytecodes, but at least it seems to work ;) [warning:
I have not tested it more than you see]
Michele Simionato
--
http://mail.python.org/mailman/listinfo/python-list
