Syntax

[calad.sigilon]

If you use 'from os import *' then you shouldn't preface the commands
with os.

So, two options:

from os import *
print "Working Path: %s" % getcwd()

OR

import os
print "Working Path: %s" % os.getcwd()

One of these two ways you're not supposed to use for security reasons,
but I'm spacing on which one.

 

[Robert Kern]

If you use 'from os import *' then you shouldn't preface the commands
with os.

So, two options:

from os import *
print "Working Path: %s" % getcwd()

OR

import os
print "Working Path: %s" % os.getcwd()

One of these two ways you're not supposed to use for security reasons,
but I'm spacing on which one.

I don't think there are any *security* reasons, but stylistically,
"import os" is greatly preferred. When someone else reads your code,
they will immediately know where getcwd() comes from.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Terry Hancock]

I don't think there are any *security* reasons, but
stylistically, "import os" is greatly preferred. When
someone else reads your code, they will immediately know
where getcwd() comes from.

It's not a question of "security" in the usual sense, but
the first syntax imports a lot of stuff into the current
namespace, increasing the risk of unintentionally clobbering
local names. So it's certainly "riskier" in the sense of
"likely to cause bugs".

 

[Fredrik Lundh]

It's not a question of "security" in the usual sense, but
the first syntax imports a lot of stuff into the current
namespace, increasing the risk of unintentionally clobbering
local names. So it's certainly "riskier" in the sense of
"likely to cause bugs".

or just "likely to result in confusing error messages".
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: an integer is required

</F>

 

[Peter Hansen]

It's not a question of "security" in the usual sense, but
the first syntax imports a lot of stuff into the current
namespace, increasing the risk of unintentionally clobbering
local names. So it's certainly "riskier" in the sense of
"likely to cause bugs".

There's also the case where the names which are imported are not static.
That is, they are bound to certain objects at the time of the "import
*" but later on they can change. While this is perhaps a sign of design
problems in the imported module, the problem that results is that when
those names are rebound, modules which imported them with "*" still have
the old objects, not the new ones. Using "import module" and
referencing things with "module.name" doesn't suffer from the same
potential for problems (in addition to it being more readable etc).

-Peter