On 3/2/2016 10:22 AM, Rustom Mody wrote:
On Tuesday, March 1, 2016 at 12:23:02 PM UTC+5:30, Terry Reedy wrote:
On 2/29/2016 7:42 AM, Rustom Mody wrote:
Is import needed at all when trying out in Idle?
...
So it does appear that
1. import not necessary with(in) idle
2. However import and f5 (ie is run as main) are different
May some idle experts elaborate on this? Whats the idle idiom of import-ing?
Rustom, since I know that you are not a rank beginner, I have trouble
understanding what you are asking.
Heh!
I know some things; dont know many things
F5 when editing foo.py is equivalent
to running "python -i foo.py" on a command line while 'in' the directory
containing foo.py. In both cases, foo.py is run as a main module, with
__name__ == '__main__'. The difference is that F5 runs foo.py under
IDLE supervision, with results going into and interactive inputs coming
from IDLE shell instead of the console interpreter.
Imports are used in a module to access objects within the imported module.
Let me try to explain again
There is import and import.
There is the formal meaning of the import keyword in python -- call it import-f
There is the informal expectation and need of programmers to 'pull something
into python' -- call it import-i
What do you mean by import-i that is different module import? Keyboard
input with input()? File input with file.read(), etcetera? Running a
file with 'python filename' or 'python -m filename'?
That there is some cognitive dissonance between import-f and import-i is seen
in the OP's question itself;
The OP's question is faulty. Repeat imports *are* allowed.
also Chris' "I dont believe the language should be changed"
So the question is around:
What is the best practice for doing import-i in python?
Since I don't know what you mean by import-i, I cannot answer.
As the OP finds import-f works once and fails thereafter
This is false. Import is a name binding statement. If a module is not
builtin, the first attempt to bind a name to a particular module has to
create the module and cache it in sys.modules. If it is builtin, the
first attempt caches the module. Subsequent attempts reuse the cached
module. Here are three imports that involve the same module. All three
run, none fail.
>>> import itertools as it
>>> import itertools as it2
>>> from itertools import count
>>> it, it2, count
(<module 'itertools' (built-in)>, <module 'itertools' (built-in)>,
<class 'itertools.count'>)
If you want to create and cache a new module of the same name, perhaps
after editing a file, delete the cache entry before importing again.
Reload does this for you. What it does not attempt to do is to change or
delete all the old bindings and references.
If one does plan to reload a module, then one should only access the
module *and its contents* via one name and keep track of any other
references to its contents, such as from instances to classes in the
module. This may be easy for a simple module of functions, but in the
general case, can be be difficult to impossible.
In idle one can get the desired result of import-i with F5
Is that right?
Having no idea what import-i is, I cannot answer. I explained F5 in my
previous answer.
Also in general is there good usecases for import-f at that interpreter prompt
As I said before, the purpose of an import is to access the contents of
module 2 from within module 1, where module1 can be the main module,
including in interactive mode. A beginner experimenting with core
python might proceed for hours without an import. Anyone experimenting
with a module must import the module first. I usually import one or
more modules in a given interactive session.
> in idle?
Whether the prompt is in a console text window or IDLE gui window is
irrelevant. The IDLE Shell gui window imitates interactive python in a
text console. It submits each statement entered to Python for execution
and displays the stdout and stderr results.
I think not but not sure of it
Here is an example use of import for learning tkinter.
>>> import tkinter as tk
As expected, nothing visible happens.
>>> root = tk.Tk()
A default master windows is created *and displayed*.
>>> b = tk.Button(root, text = 'hello world')
Nothing visible happens.
>>> b
<tkinter.Button object .2092827275560>
But an instance of the class was created.
>>> b.grid()
Button appears. Master window shrinks to fit.
>>> t = tk.Toplevel(root)
A new toplevel window appears.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
