On Sat, Feb 1, 2014 at 12:14 PM, Scott W Dunning <swdunn...@cox.net> wrote: > Thanks Chris! > > Also, before I forget what is the difference between / and //? I remember > something about floor division?
In Python 2, the / operator by default is "floor division". 5 divided by 2 is 2. When you divide two integers, you get back an integer. In Python 3, the / operator is "sorta kinda real number division", in that it does what you're more likely to expect: 5 divided by 2 is 2.5. You'll get back a floating point number instead of an integer. You can ask Python 2 to give you the Python 3 behaviour by putting this at the top of your script: from __future__ import division Regardless of whether you're on Py2 without the future directive, Py2 with the future directive, or Py3, you can use the // operator to get the behaviour of floor division. Since that behaviour is exactly what you want when you're working with modulo, it may be worth getting into the habit of using it. But then again, it may not. You'll have other changes to make when you move to Python 3, so you can just figure it out then. (Incidentally, if there's nothing keeping you on Python 2, you may want to move sooner rather than later. There are lots of awesome features in Python 3 that will never be added to Python 2.) > Also, I think I found out through a little trial and error that I had two > different hours, mins, and sec so I had to use one uppercase and one lower > case. Is that frowned upon? And should I have come up with a different name > instead? > > SECONDS = 1 > MINUTES = 60 * SECONDS > HOURS = 60 * MINUTES Well, an ALL_UPPERCASE_NAME is generally a constant, which is how you're using them here. So in this specific instance, what you've done is fine. But don't treat this as a way to get yourself a few more variable names; if you'd done these ones in lower case and the other ones in caps, it would have been extremely confusing to an experienced Python programmer. For some style tips that a lot of Python programs follow, check out PEP 8: http://www.python.org/dev/peps/pep-0008/ Formally, this is the style guide for the Python standard library, but it's a fairly sensible set of rules, and a lot of projects follow them. Some of the rules are widely adopted elsewhere, others (like the insistence on spaces rather than tabs - everyone agrees that you should use one OR the other, but plenty of people advocate tabs above spaces) less so; take your pick which bits you follow, but all of it is worth a read. > time_left_house = 6 * HOURS + 52 * MINUTES > > miles_run_easy_pace = 2 * (8 * MINUTES + 15 * SECONDS) > > miles_run_fast_pace = 3 * (7 * MINUTES + 12 * SECONDS) > > time_returned_home = miles_run_easy_pace + miles_run_fast_pace + > time_left_house > > hours = time_returned_home // HOURS > part_hour = time_returned_home % HOURS > minutes = part_hour // MINUTES > seconds = part_hour % MINUTES > > print "Time returned home:", hours,":", minutes,":", seconds,”am" Looks fairly good. This is where you could use the formatting notation I gave you above: print "Time returned home: %02d:%02d:%02d am" % (hours, minutes, seconds) And then, since you're using print with a single string argument, get in the habit of putting parentheses around it: print("Time returned home: %02d:%02d:%02d am" % (hours, minutes, seconds)) This syntax (one string argument, parens around it) is common to both Python 2's print statement and Python 3's print function (as with division, you can ask Python 2 to give you a print function if you wish). So, is the program giving you the result you expect? That's really the key. If it is, then you (probably!) have a working program! ChrisA -- https://mail.python.org/mailman/listinfo/python-list
