Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #103686 > unrolled thread

Reason for not allowing import twice but allowing reload()

Back to article view | Back to comp.lang.python

Contents

  Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-28 22:40 -0800
    Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-02-29 18:01 +1100
      Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-01 22:18 +1100
        Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-01 22:39 +1100
          Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-02 04:11 +1100
            Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-02 05:04 +1100
        Re: Reason for not allowing import twice but allowing reload() Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-01 14:53 -0700
        Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-02 09:02 +1100
        Re: Reason for not allowing import twice but allowing reload() Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-01 15:29 -0700
          Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-02 12:19 +1100
            Re: Reason for not allowing import twice but allowing reload() Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-01 19:22 -0700
              Re: Reason for not allowing import twice but allowing reload() Rustom Mody <rustompmody@gmail.com> - 2016-03-02 02:15 -0800
                Re: Reason for not allowing import twice but allowing reload() Rustom Mody <rustompmody@gmail.com> - 2016-03-02 02:19 -0800
              Re: Reason for not allowing import twice but allowing reload() Grant Edwards <invalid@invalid.invalid> - 2016-03-02 15:15 +0000
        Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-02 11:13 +1100
    Re: Reason for not allowing import twice but allowing reload() Ian Kelly <ian.g.kelly@gmail.com> - 2016-02-29 00:02 -0700
    Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-02-29 18:11 +1100
      Re: Reason for not allowing import twice but allowing reload() BartC <bc@freeuk.com> - 2016-02-29 15:33 +0000
        Re: Reason for not allowing import twice but allowing reload() Chris Angelico <rosuav@gmail.com> - 2016-03-01 03:05 +1100
    Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Rustom Mody <rustompmody@gmail.com> - 2016-02-29 04:42 -0800
      Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Terry Reedy <tjreedy@udel.edu> - 2016-03-01 01:52 -0500
        Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Rustom Mody <rustompmody@gmail.com> - 2016-03-02 07:22 -0800
          Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Terry Reedy <tjreedy@udel.edu> - 2016-03-02 21:40 -0500
            Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Rustom Mody <rustompmody@gmail.com> - 2016-03-02 20:07 -0800
              Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload()) Rustom Mody <rustompmody@gmail.com> - 2016-03-02 20:17 -0800
    Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-29 05:00 -0800
    Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-29 05:22 -0800
      Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-29 05:25 -0800
        Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-02 04:00 +1100
          Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-03-05 04:51 -0800
            Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-10 00:53 +1100
      Reason for not allowing import twice but allowing reload() Rustom Mody <rustompmody@gmail.com> - 2016-02-29 05:51 -0800
        Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-02-29 07:13 -0800
      Re: Reason for not allowing import twice but allowing reload() Terry Reedy <tjreedy@udel.edu> - 2016-03-01 02:04 -0500
    Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-03-06 00:20 -0800
      Re: Reason for not allowing import twice but allowing reload() Steven D'Aprano <steve@pearwood.info> - 2016-03-07 01:50 +1100
    Re: Reason for not allowing import twice but allowing reload() alien2utoo@gmail.com - 2016-03-06 00:31 -0800

Page 2 of 2 — ← Prev page 1 [2]

#103778 — Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload())

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.  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.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#103877 — Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload())

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

That there is some cognitive dissonance between import-f and import-i is seen
in the OP's question itself; 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?
As the OP finds import-f works once and fails thereafter

In idle one can get the desired result of import-i with F5
Is that right?

Also in general is there good usecases for import-f at that interpreter prompt
in idle?
I think not but not sure of it

[toc] | [prev] | [next] | [standalone]

#103931 — Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload())

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

[toc] | [prev] | [next] | [standalone]

#103935 — Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload())

On Thursday, March 3, 2016 at 8:11:20 AM UTC+5:30, Terry Reedy wrote:
> 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'?

I define something... either with
def foo()...
or
x = ...

I want to see what foo does/what x is
I want to check that my understanding of these matches python's representation
of the same.
I could keep typing the the
def foo()...
but that can get painful quickly

So I put these in a file...
And import!

At this point I am pleased
Because what I expect of import (import-i)
and what python does with the import keyword (import-f) match... seemingly

Until I go and change the def in the file and run the import again
Fails
Restart python -- works

> 
> > 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.

Thanks
Thats a good example

As far as I can see, its an example of importing a standard/system module.
Any example of usefully running import-f (ie the keyword) with modules under
development?

[toc] | [prev] | [next] | [standalone]

#103936 — Re: Correct IDLE usage (was Reason for not allowing import twice but allowing reload())

On Thursday, March 3, 2016 at 9:38:11 AM UTC+5:30, Rustom Mody wrote:
> On Thursday, March 3, 2016 at 8:11:20 AM UTC+5:30, Terry Reedy wrote:
> > 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'?
> 
> I define something... either with
> def foo()...
> or
> x = ...
> 
> I want to see what foo does/what x is
> I want to check that my understanding of these matches python's representation
> of the same.
> I could keep typing the the
> def foo()...
> but that can get painful quickly
> 
> So I put these in a file...
> And import!
> 
> At this point I am pleased
> Because what I expect of import (import-i)
> and what python does with the import keyword (import-f) match... seemingly
> 
> Until I go and change the def in the file and run the import again
> Fails
> Restart python -- works

Just to be clear, I dont believe the problem is with import-f per se
It is with overloading python to be both scripting engine and interactive interpreter.

Both ruby and haskell find it expedient to separate the two
Ruby has irb and ruby
Haskell has ghc (compiler), runhaskell (scripting) ghci (interpreter)

[toc] | [prev] | [next] | [standalone]

#103703

Thanks Chris and Ian,

Your suggested experiments and explanations have really provided some good insights, something Tutorial didn't indicate.

Ian's explanation reminds me of 

#ifndef _HEADER_H_
#define _HEADER_H_
...
#endif  // _HEADER_H_

in C/C++, and I can draw parallels to why subsequent attempts to import same module shouldn't result in flagging an error, and need for multiple imports to refer to same information.

[toc] | [prev] | [next] | [standalone]

#103705

Hello Rustom,

F5 in Idle restarts the Python interpreter (that's what my impression is). Whatever you have done earlier at Idle prompt (in Idle session) before F5 is gone after F5.

Try simple experiment at prompt.

>>> myvar="hello"
>>> myvar
'hello'

myvar is gone after F5.

As for need of import in Idle session, I use it to
- import sys
- sys.append.path('D:\\Where\\Ever\\My\\Modules\\Lie')
- import mymodule

[toc] | [prev] | [next] | [standalone]

#103706

> As for need of import in Idle session, I use it to
> - import sys
> - sys.append.path('D:\\Where\\Ever\\My\\Modules\\Lie')

Kindly read above as
sys.path.append(....)

> - import mymodule

[toc] | [prev] | [next] | [standalone]

#103802

On Tue, 1 Mar 2016 12:25 am, alien2utoo@gmail.com wrote:

>> As for need of import in Idle session, I use it to
>> - import sys
>> - sys.append.path('D:\\Where\\Ever\\My\\Modules\\Lie')
> 
> Kindly read above as
> sys.path.append(....)
> 
>> - import mymodule


There are better ways to manage your Python path than to manually insert
paths into sys.path like that. What version of Python are you using?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#104094

Steven,

> There are better ways to manage your Python path than to manually insert
> paths into sys.path like that. What version of Python are you using?

I would love to know, apart from PYTHONPATH and sys.path.append() route.

I am using Python 2.7.11 to start with as suggested by my employer.

[toc] | [prev] | [next] | [standalone]

#104409

Sorry for the delay in answering!

On Sat, 5 Mar 2016 11:51 pm, alien2utoo@gmail.com wrote:

> Steven,
> 
>> There are better ways to manage your Python path than to manually insert
>> paths into sys.path like that. What version of Python are you using?
> 
> I would love to know, apart from PYTHONPATH and sys.path.append() route.
> 
> I am using Python 2.7.11 to start with as suggested by my employer.

Python creates sys.path from four different sources:

(1) The directory of the script you are running, if you are running a
script, otherwise the current directory.

(2) Any paths listed in the PYTHONPATH environment variable.

(3) A small number of fixed paths, which are built into the interpreter.

(4) Finally the site.py module does extensive customization of sys.path.

If you have just one or two paths to add, PYTHONPATH is the easiest and most
convenient. But for more extensive additions to the path, number (4) is the
way to go. It gives you many options!

Let's suppose I want to add two locations to my path alone, not for any
other users:

/home/loretta/python
/home/loretta/scripts


Here are four methods for adding user-specific locations to sys.path, plus
two more for adding system-wide locations that apply to all users:



Method 1: PYTHONPATH environment variable
=========================================

In my ~/.bashrc file, I put this line:

export PYTHONPATH="/home/loretta/python:/home/loretta/scripts"



Method 2: startup file
======================

(This method only works when I run the interactive interpreter, not when
running scripts.)

In my ~/.bashrc file, I put this line:

export PYTHONSTARTUP="/home/loretta/startup.py"


Then I edit startup.py to include any python code I like:

print "Running Python startup file..."
import sys
sys.path.append('/home/loretta/python')
sys.path.append('/home/loretta/scripts')
print "Done!"



Method 3: usercustomize.py
==========================

I create a file:

~/.local/lib/python2.7/site-packages/usercustomize.py


which can contain any Python code I like. Import sys and add to the path:

import sys
sys.path.append('/home/loretta/python')
sys.path.append('/home/loretta/scripts')



Method 4: user .pth file
========================

I create a file containing the paths I want to add, one path per line:


/home/loretta/python
/home/loretta/scripts


Blank lines and lines starting with # are ignored.

I save this to:

~/.local/lib/python2.7/site-packages/loretta.pth

I can have as many .pth files as I like, and name them anything I like, so
long as the names end with .pth and they are in my local site packages
directory.



Method 5: sitecustomize.py
==========================

This is like usercustomize.py (method 3), except it applies to all users.

Create a file sitecustomize.py, and put it in Python's standard library,
which is usually found here:

/usr/local/lib/python2.7/

You will need to be root to do this.


Method 6: site .pth file
========================

This is like method 4, except it applies to all users.

Create a .pth file containing the paths you want added, and put it in
Python's standard library. You will need to be the root user to do this.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#103709

On Monday, February 29, 2016 at 6:53:09 PM UTC+5:30, alien...@gmail.com wrote:
> Hello Rustom,
> 
> F5 in Idle restarts the Python interpreter (that's what my impression is). Whatever you have done earlier at Idle prompt (in Idle session) before F5 is gone after F5.
> 
> Try simple experiment at prompt.
> 
> >>> myvar="hello"
> >>> myvar
> 'hello'
> 
> myvar is gone after F5.
> 
> As for need of import in Idle session, I use it to
> - import sys
> - sys.append.path('D:\\Where\\Ever\\My\\Modules\\Lie')
> - import mymodule

Why does one use (something like) idle?
To experiment.

So what's your experiment-focus?
If it is mymodule then mymodule should be open in idle file window and idle will take care of paths

If its someothermodule.py that has an import of mymodule.py then
someothermodule should be handling the paths issue.

In neither case I see a reason to do it at idle prompt

[At least that's my understanding, hope an idle expert will weigh in on this]

In linux this question does not typically arise as one starts idle from the shell in the same directory as the python files one wants to play with

In windows... not sure of idiom...
Maybe right-click the idle icon and change its 'start-in' to the path where
your python files are situated?

My general impression (best-practices not semantics) is that changing sys.path
is allowed but hackish.
1. Modify sys.path
2. Using PYTHONPATH env variable
3. Use relative imports
4. Use packages
?. .pth files

is roughly decreasing in hackishness though unfortunately increasing in sophistication

http://stackoverflow.com/questions/19917492/how-to-use-pythonpath
http://stackoverflow.com/questions/18521503/pydev-how-to-avoid-adding-sub-directories-to-python-path-in-order-to-fix-unres

[toc] | [prev] | [next] | [standalone]

#103718

> Why does one use (something like) idle?
> To experiment.
> 
> So what's your experiment-focus?

True. Experiment only.
What happens (and in environment) when you use
- import module
- from module import name
- from module import name as othername

Idle is start point, but we aren't always going to be Idle-ing, so need to work towards that as well while practicing basic concepts.

[P.S.- I think we are digressing a lot from original thread question.]

[toc] | [prev] | [next] | [standalone]

#103779

On 2/29/2016 8:22 AM, alien2utoo@gmail.com wrote:
> Hello Rustom,
>
> F5 in Idle restarts the Python interpreter (that's what my impression is).

More exactly, IDLE runs user code in a separate process from the one 
that runs the IDLE gui.  Restarting means that the existing user process 
is terminated and a new one started.  This is easier than trying to 
'clean up' the existing process.

If you start python with '> python' in a terminal, then restarting the 
interactive interpreter means '>>> quit' at the interactive prompt 
followed by "> python" in the console.  You do the equivalent in IDLE 
Shell with 'control-F6' or 'Shell -> Restart Shell.

F5 when editing path/file.py replaces the command 'python' with 'cd 
path' followed by 'python -i file.py'

Maybe I should add something to the IDLE doc for people familiar with 
using python in a console.  (Most beginners are not.)

> Whatever you have done earlier at Idle prompt (in Idle session)
 > before F5 is gone after F5.

Yes, the same as if you quit().  A change I would like to make sometime 
is to have F5 run the file is a new user process without killing the old 
one, so one does not loose work done in Shell.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#104124

Based on the input from members, and my subsequent reading the textbook/tutorials, let
me summarize my understanding of "why subsequent imports of same module are designed to be effect-less".

1. Imports are costly affair, as it involves
 - finding the module's file
 - compile it to byte code (if needed)
 - run the module's code to build the objects it defines.

2a. Quoting from "Learning Python: Mark Lutz" : In Python, cross-file module linking
    is not resolved until such import statements are **executed at runtime**.

import being a statement, can come anywhere a statement can, so a module can be
selectively imported depending upon the conditions at runtime.

2b. Inter-dependencies between modules: For example, A (main module) imports B, C, D
    and E. B again imports C and E, D imports B and C.

If import statements are processed entirely from scratch each time, it would amount
to lot of **redundant (and costly)** work.

Secondly there could be dangerous? side-effects of reprocessing imports from scratch.

Let us say, in above example, module B does some initialization of variables, or
things like resetting a file for further work during the session. These variables and
file are updated during the course of execution of A.

Much later via some conditional path, module B is imported again, and BOOM (were
import processed from scratch again).

In this case - we are respecting that every import of a module should give same
picture (assuming it is not modified across two different invocation during the
program execution).

An argument here could be: to code module B in such a way that those initializations
don't happen again, but just once - check before resetting etc. during the import.
But wouldn't that violate the *same picture* requirement?

Probably my example is not that perfect.

[toc] | [prev] | [next] | [standalone]

#104145

On Sun, 6 Mar 2016 07:20 pm, alien2utoo@gmail.com wrote:

> Based on the input from members, and my subsequent reading the
> textbook/tutorials, let me summarize my understanding of "why subsequent
> imports of same module are designed to be effect-less".

That is not correct. Imports are not a no-op, they always have an effect.
The effect is that they bind the module to a name in the current namespace.

What import does NOT do is *reload the module* from disk. But that's not the
same thing as being "effect-less".


> 1. Imports are costly affair, as it involves
>  - finding the module's file
>  - compile it to byte code (if needed)
>  - run the module's code to build the objects it defines.

Correct.


> 2a. Quoting from "Learning Python: Mark Lutz" : In Python, cross-file
> module linking
>     is not resolved until such import statements are **executed at
>     runtime**.

I don't understand that statement.


> import being a statement, can come anywhere a statement can, so a module
> can be selectively imported depending upon the conditions at runtime.

Correct.


> 2b. Inter-dependencies between modules: For example, A (main module)
> imports B, C, D
>     and E. B again imports C and E, D imports B and C.
> 
> If import statements are processed entirely from scratch each time, it
> would amount to lot of **redundant (and costly)** work.
> 
> Secondly there could be dangerous? side-effects of reprocessing imports
> from scratch.

Correct.


> Let us say, in above example, module B does some initialization of
> variables, or things like resetting a file for further work during the
> session. These variables and file are updated during the course of
> execution of A.
> 
> Much later via some conditional path, module B is imported again, and BOOM
> (were import processed from scratch again).

Correct. This would be a bad thing.


> In this case - we are respecting that every import of a module should give
> same picture (assuming it is not modified across two different invocation
> during the program execution).
> 
> An argument here could be: to code module B in such a way that those
> initializations don't happen again, but just once - check before resetting
> etc. during the import.

How would you do that? How could a .py file know if it has already been
loaded?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#104125

From the discussions in this thread, I get the impression that there are genuine
requirements to reload() a module during a program's execution.

It is fairly easy to see reload() in context of interactive execution, but how does it
come into picture in case of non-interactive Python program executions?

- one way could to be periodically poll for change of module version (time stamp etc.),
  and reload(),
- other could be sending a signal to program and reload() selected modules during
  processing of that signal by the program. Is it done this way in Python as well?

  There used to be programs which could reload the configuration file (and act
  accordingly) without needing to restart the program) when specific signal was sent
  to them.

Am I on right track in my understanding?
What are the other ways to accomplish reload() during the execution of a non-interactive Python program?

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web