Luke Paireepinart wrote:
Ray, please reply on-list in the future in case someone else has input.
On Fri, Mar 12, 2010 at 8:01 PM, Ray Parrish <c...@cmc.net
<mailto:c...@cmc.net>> wrote:
Luke Paireepinart wrote:
print "A %s with dimensions %sx%s has an area of %s." %
(choice, height, width, width*height)
Isn't it a little more understandable to use a construct like the
following?
>>> print "The area of a " + Choice + "is " str(Width) + " x " +
str(Height) + " equals " + str(Width * Height) + " square feet"
The area of a rectangle is 12 x 10 equals 120 square feet.
I find that putting the variables on the end like that, when
you're not actually applying any special formatting to them makes
it less readable when I'm debugging my stuff, or when someone else
is reading my code, and trying to understand it.
Your version creates at least 10 intermediate strings before outputting.
Remember strings are immutable in Python.
So you're constructing strings
The area of a
The area of a rectangle
The area of a rectangle is
12
The area of a rectangle is 12
The area of a rectangle is 12 x
10
The area of a rectangle is 12 x 10
The area of a rectangle is 12 x 10 equals
120
The area of a rectangle is 12 x 10 equals 120
The area of a rectangle is 12 x 10 equals 120 square feet
With string formatting you avoid all of these intermediate strings, so
it's arguably more efficient.
Other than just viewing from a performance standpoint though, I find
it much easier to read my version, because any computation required
takes place at the end of the line.
For example, your inline str(width*height) requires you to read the
whole line to see it.
It's really a personal thing, it's easier for me to read the
formatting version than the string concatenation version, in most cases.
Now if you had used the comma convention I would have seen your
point. This is, I think, the easiest to read of all 3
area = width * height
print "The area of a", choice, "is", width, "x", height, ", which
equals", area, "square feet."
Also, why are you capitalizing variable names? That's a pretty
unusual convention.
-Luke
Thanks for letting me know how inefficient my method is. I'll remember
that, and apply your suggestions to my code from now on. So, you're
saying that the commas method also does not suffer from the overhead of
creating a bunch of individual strings?
As far as the capitalizations, it's just a habit I've held over from my
Visual Basic days, and earlier programming. It's a little easier for me
to pick out the individual words in a variable like ThisPerson as
opposed to thisperson. I have been made aware that Python standard
coding practice requires lower case variable names, and as soon as I can
force myself to do it that way, or can remember to post that way I will
be adopting the in place standards and conventions.
Is it actually supposed to be this_person? I read part of the standards
document, but can not remember right off the top of my head if
underlines between words is required.
Thanks, Ray Parrish
--
Linux dpkg Software Report script set..
http://www.rayslinks.com/LinuxdpkgSoftwareReport.html
Ray's Links, a variety of links to usefull things, and articles by Ray.
http://www.rayslinks.com
Writings of "The" Schizophrenic, what it's like to be a schizo, and other
things, including my poetry.
http://www.writingsoftheschizophrenic.com
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
