advice on this little script

S

Steve Holden

Paul said:
Besides the bug mentioned, I don't think you should really do it that
way, since sleep(60.0) might not sleep for exactly 60 sec (it could be
longer or shorter). Preferable is something like (untested):

now = time.time()
sleep_until = now + 60*minutes
while now < sleep_until:
print int((now - sleep_until)/60), 'minutes remaining'
sleep (60)
now = time.time()

You might actually want to stop sleeping a little bit early (say if
you wake up 5 seconds before sleep_until), or round the message to the
nearest number of minutes, etc.

You might also want to synchronize to a caesium clock, but the guy is
timing his laundry, for Pete's sake! Can we agree your approach, while
theoretically sound, might be a little over-complicated for a first
application?

regards
Steve
 
K

Kent Johnson

I use both fairly interchangeably. When I just need one or two things
from the module, or if I am going to use something a lot, I use from xx
import yy.
I only use the 'from' statement to import specific modules from a
package, never to import specific objects (functions, classes, or
whatever) from a module. It scales much better: when reading a long
module, I _know_ that any barename X always refers to a local,
nested-scope, or global name, never to something snatched from
who-recalls-what module -- in the latter case I'll never see a barename,
but always somemodule.X, and searching for '... import somemodule' will
immediately tell me where somemodule was coming from (should I need to
be reminded of that information).

If you use from xx import yy, searching for yy will show you its
provenance as well.

From xx import * is evil because it does hide the provenance of names.
It can also give unexpected results - if xx contains from zz import *,
then all of the names from zz will also be imported into the module
importing xx!

Kent
 
J

John Salerno

Steve said:
You might also want to synchronize to a caesium clock, but the guy is
timing his laundry, for Pete's sake! Can we agree your approach, while
theoretically sound, might be a little over-complicated for a first
application?

LOL. Thanks, I was about to fall out of my chair! :)
 
J

John Salerno

Alex said:
I only use the 'from' statement to import specific modules from a
package, never to import specific objects (functions, classes, or
whatever) from a module.

I like that. So in my case I'd use 'import time' (which I actually
already changed last night). I think especially right now, while I'm new
to Python, it helps me to see 'time.sleep' instead of just 'sleep', so I
can begin to associate certain functions with their proper modules.

Not to mention, like you said, that importing specific pieces like
functions tends to look a little messy in the code when they aren't
qualified.
 
A

Alex Martelli

Kent Johnson said:
If you use from xx import yy, searching for yy will show you its
provenance as well.

But when seeing the barename yy, it gives no clue whether the module
you're reading used 'from xx import yy' or defined yy in any other way
(localy, globally, or in any intermediate scope).

'from' has many other disadvantages, such as working badly with reload
_except_ when used specifically to import a module.


Alex
 
A

Alex Martelli

John Salerno said:
I like that. So in my case I'd use 'import time' (which I actually
already changed last night). I think especially right now, while I'm new
to Python, it helps me to see 'time.sleep' instead of just 'sleep', so I
can begin to associate certain functions with their proper modules.

I'm hardly new to Python, yet it keeps helping me too;-).

Not to mention, like you said, that importing specific pieces like
functions tends to look a little messy in the code when they aren't
qualified.

I wouldn't call it messy, but rather potentially "confusing" in a large
module with many imports -- in the middle of the module,

a = b(c)

always gives the strong impression that b and cc are local or global (or
from an intermediate lexical scope), while

a = X.b(Y.c)

contains hints suggesting otherwise (if I had no clue what X and Y were
at this point, I'd _first_ check if they were imported modules, while it
would be my last resort in the former snippet regarding b and c).


Alex
 
B

BartlebyScrivener

There are several of these writing quotes, all good in their own way,
because they emphasize concision as the first order of business for any
writer.

"If I had more time, I would write a short letter."--Blaise Pascal

"If the author had been less industrious, this book would be twice as
long."--Evelyn Waugh

Telegram from Mark Twain's publisher: "NEED 2-PAGE SHORT STORY IN TWO
DAYS." Twain replied: "NO CAN DO 2 PAGES TWO DAYS. CAN DO 30 PAGES 2
DAYS. NEED 30 DAYS TO DO 2 PAGES."

rpd
http://dooling.com
 
B

BartlebyScrivener

You might also want to synchronize to a caesium clock, but the guy is
timing his laundry, <<

My morning coffee just streamed out of my nose. Air. I need air.

rpd
 
C

Carl Banks

John said:
Very picky point, but I'd like to know what others think of this. Should
I import as above, or should I do this:

import time
....
time.sleep(60.0) ???

I think the 'from time import sleep' looks cleaner, because I'm only
taking what I need (is an import any more expensive than this from?),
but I also feel like the 'time.sleep' syntax is much more
self-describing and better to read than just 'sleep'.

So what do you guys think between these two choices?

I used to do both, depending on what was more convenient. These days,
as I've been writing larger and more complex programs, I pretty much
just import the module. I find that a consistent approach just keeps
things easier to digest, gives me less to think about and fewer
decisions to make. One can consistently import the module, but not the
symbols within because sometimes there's just too many.

The exception is I still import global singleton objects using
from...import. Such objects behave more like modules in my code
anyways, and probably they'd actually be modules if not for the
ugliness of using the global statement.

Having said all that, I still cringe slightly when writing stuff like
glob.glob() and time.time(). (Which brings me to a related piece of
advice: a good way to name modules that avoids confusion with other
symbols is to use "act of" words, i.e., words that end in ing, ion,
age, or ment. I would have named the glob module "globbing", the time
module "timing", and so on; then I wouldn't have to cringe.)


Carl
 
T

Terry Reedy

John Salerno said:
I'd prefer to be platform neutral when possible. Is the first option
that, or does this change depending on OS?

It is display dependent what display does with control codes. \007 is ANSI
ascii control char which only works to beep on ansi terminals or emulation
thereof. On PCs and Windows, displays have extended char set that prints
most all char codes. \007 prints as a square box. IBM EBCDIC terminals
would probably do third thing.

Terry Jan Reedy
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top