[Tutor] Hotfolder 1st attempt

[Daniel Yoo]

> Daniel Yoo wrote:
> 
> > On Mon, 6 Nov 2000, Scott Ralph wrote:
> >
> > > from time import *
> > > from stat import *
> >
> > The only thing I could point out is that you might not want to import
> > everything within time or stat.  You can be more specific, like:
> >
> >     from time import sleep
> >
> > It's considered good practice to pull out only the functionality that you
> > need from modules; that way, people can see exactly which functions you're
> > using from other modules.

> Thanks for the feedback, I removed the S_ISREG(mode) I didn't need it.  
> Does your first suggestion also speed things up? from time import
> sleep.  Thanks again for the feedback.


It's not really a matter of a speedup.  The main reason for importing
those functions explicitly is to get in the habit.  Otherwise, you might
get bitten by naming conflicts between modules later on.  These conflicts
can occur more regularly than you'd expect.  For example, you take a look
at the index of all functions here:

    http://python.org/doc/current/lib/genindex.html

and you'll see that at least 20 separate modules define their own
open() method!


This makes more sense with a small example with the math and cmath
modules.

    http://python.org/doc/current/lib/module-math.html
    http://python.org/doc/current/lib/module-cmath.html

cmath does almost the same stuff as math, except that cmath's functions
can work with complex numbers.  If we look, we'll notice that they have
exactly the same function names.  So if we did something like this:

###
>>> from cmath import exp
>>> from math import *   # <--- bad, bad!
>>> print exp(10 + 2j)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: can't convert complex to float; use e.g. abs(z)
###

we'd get confused for a long time, until we see that exp() is math's
definition of exp(), not cmath's.  This is obviously an artificial
example, but I've seen many situations like this to be wary.

Perhaps the Python implementers would be willing to define a safer
importing scheme that would give a warning if naming conflicts occur.  
Until then, you'll need to be careful, and avoid using 'from module import
*' unless that module is designed well.

Hope this helps!