newbie: self.member syntax seems /really/ annoying

[J. Clifford Dyer]

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

 

[OKB (not okblacke)]

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

 

[Carsten Haese]

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.

 

[Bjoern Schliessmann]

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

 

[Wildemar Wildenburger]

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 n>1 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

 

[Bruno Desthuilliers]

Wildemar Wildenburger a écrit :

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 n>1 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 ?-)

 

[Carl Banks]

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

 

[Wildemar Wildenburger]

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.

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

 

[stef mientki]

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

 

[Wildemar Wildenburger]

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

 

[Steven D'Aprano]

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.

 

[stef mientki]

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

 

[Steven D'Aprano]

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.

 

[Bjoern Schliessmann]

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

 

[stef]

Well, those cost money ...

Maxima doesn't

cheers,
Stef

 

[Colin J. Williams]

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.

 

[Ben Finney]

.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.