NameError: name 'os' is not defined

[lrpirlet]

Hello
I am new to coding python and to this forum… If I do come with a NOOB question, please tell me..
My question is: what is the difference between import <a module> and from <a module> import *…

I am working at the console of IDLE running under windows 10.
Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 23:03:10) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.

If I type

>>> import os
>>> type(os)
<class 'module'>
>>> dir(os)
['DirEntry', 'F_OK', 'MutableMapping', <cut> , 'getcwd', <cut>
>>> getcwd

Error:
Traceback (most recent call last):
  File "<pyshell#6>", line 1, in <module>
    getcwd
NameError: name 'getcwd' is not defined

>>> getcwd()

Error:
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in <module>
    getcwd()
NameError: name 'getcwd' is not defined

Now, I use the other form of import…

>>> from os import *
>>> getcwd
<built-in function getcwd>
>>> getcwd()
'C:\\Program Files\\Python38'

So either I do something wrong or there is a problem… I did some search and found this problem reported on GitHub… BUT it could not be reproduced…

Please note that I have this behaviour any time I start a new python shell via the icon… This is true for other module than os… I have the same effect with math…

Is "import <a module>" not often used in favour of "from <a module> import <what needed> ???

Thanks in advance.

[buran]

1. when you do import os you need to fully qualify which function you want to use e.g. os.getcwd()
2. alternative is to do from os import getcwd, then you can do detcwd()
3. the worst (discouraged) approach is to use star import - from os import *

In all 3 cases the full module is imported.
the difference between 1 and 2 is what name(s) are available to you
in 3, all names are available, but this make it difficult to know/follow what is imported from where. Also if you import same name from different modules/packages one will override the other name.

[lrpirlet]

Hello, Thanks a lot, I understand that what you propose is best practice from experienced people...

Do you mean that import os has changed in a recent version? I am following this book from Gerard Swinnen univesité de Liège…
According to this book, during the whole introduction, I am asked to type from <module> import * .. Only in chapter 11 do I get to type import os where it failed…

Never mind, that is ok, thanks a lot, I will not use this form if it causes troubles and I have a least 3 different ways to get what I need...

Before you ask I am not a student, I am just a retired engineer…

[buran]

PEP8 is explicit on wildcard imports

Wildcard imports (from <module> import *) should be avoided, as they make it unclear which names are present in the namespace, confusing both readers and many automated tools. There is one defensible use case for a wildcard import, which is to republish an internal interface as part of a public API (for example, overwriting a pure Python implementation of an interface with the definitions from an optional accelerator module and exactly which definitions will be overwritten isn't known in advance).

If you are interested, here is something from our tutorial section:
https://python-forum.io/Thread-Namespace...th-imports

and a recent thread where the problem was caused exactly from using star import
https://python-forum.io/Thread-Flask-add...#pid108659

[buran]

Do you mean that import os has changed in a recent version? I am following this book from Gerard Swinnen univesité de Liège…
According to this book, during the whole introduction, I am asked to type from <module> import * .. Only in chapter 11 do I get to type import os where it failed…

No, no change in os module. This is how import works in python. That's not just about os module. It's how it work with every module

[lrpirlet]

OK, Buran, Thanks a lot… for your patience and expertise.

I read the book back again after your interventions… and some reading you proposed.
Well, do I need to get back to primary school? I'll take for excuse that the brain continue see what it first decoded…

The exact sequence was

>>> import os
>>> os.getcwd()
'C:\\Program Files\\Python38'

I was missing the os. part…

The module was bound, the function in the module were not, even if I could see all the available function… I need to explicitly tell where that function name can be found.
On the other side, using from os import getcwd, I can use it without reference to os (did I get it right now?)

And again, thanks for your help. I now see how names from one module could overwrite another one.

[buran]

I was missing the os. part…

The module was bound, the function in the module were not, even if I could see all the available function… I need to explicitly tell where that function name can be found.

yes. that is 1. from my previous list. you can access functions, classes from that module

On the other side, using from os import getcwd, I can use it without reference to os (did I get it right now?)

yes, that is 2. from my list

something from our tutorial section
https://python-forum.io/Thread-Basic-Modules-part-1