[Tutor] First program
crp at cmc.net
Sat Mar 13 19:04:07 CET 2010
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 <crp at cmc.net
> <mailto:crp at 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
> >>> 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
> The area of a rectangle is 12
> The area of a rectangle is 12 x
> The area of a rectangle is 12 x 10
> The area of a rectangle is 12 x 10 equals
> 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.
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..
Ray's Links, a variety of links to usefull things, and articles by Ray.
Writings of "The" Schizophrenic, what it's like to be a schizo, and other
things, including my poetry.
More information about the Tutor