[Tutor] First program

Ray Parrish 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
>     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




More information about the Tutor mailing list