autoreload fails to work

[wting]

with v0.12.1

Python 2.7.3 (default, Aug  1 2012, 05:16:07)
Type "copyright", "credits" or "license" for more information.

IPython 0.12.1 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: %load_ext autoreload

In [2]: %autoreload 2

In [3]: %aimport foo

In [4]: %aimport
Modules to reload:
all-except-skipped

Modules to skip:


In [5]: foo.bar()
Out[5]: 1

In [6]: foo.bar()
Out[6]: 1

In [7]: reload(foo)
Out[7]: <module 'foo' from 'foo.py'>

In [8]: foo.bar()
Out[8]: 2

In [9]: 

with v1.0-dev:

Python 2.7.3 (default, Aug  1 2012, 05:14:39)
Type "copyright", "credits" or "license" for more information.

IPython 1.0.dev -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: %load_ext autoreload

In [2]: %autoreload 2

In [3]: %aimport foo

In [4]: import foo

In [5]: %aimport
Modules to reload:
all-except-skipped

Modules to skip:


In [6]: foo.bar()
1

In [7]: foo.bar()
1

In [8]: reload(foo)
Out[8]: <module 'foo' from 'foo.py'>

In [9]: foo.bar()
2

In [10]: 

[wting]

Closing as this seems to be an environment problem. I'll update this issue once I find the cause.

[wting]

The problem is caused by export PYTHONDONTWRITEBYTECODE=1 in my ~/.zshrc.

[takluyver]

I'm a bit puzzled why that environment variable disrupts autoreload, but I
can easily imagine that we haven't tested with it. If there's a simple fix,
I think we'd be happy to merge it.

On 24 February 2013 21:48, William Ting notifications@github.com wrote:

The problem is caused by export PYTHONDONTWRITEBYTECODE=1 in my ~/.zshrc.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2976#issuecomment-14016851.

[bfroehle]

I think it's because we determine if the module is stale by comparing the mtime of the .py and .pyc files. Without this comparison, I'm not sure we can determine if a reload is necessary. (But we could resort to always reloading in such a case?)

[wting]

I'm ok with the latter option of always reloading. Sure it may be inefficient, but people who are manually disabling bytecode caching consciously made that choice.

[takluyver]

Ah, that sounds like it. Pull requests welcome.

On 25 February 2013 06:07, William Ting notifications@github.com wrote:

I'm ok with the latter option of always reloading. Sure it may be
inefficient, but people who are manually disabling bytecode caching
consciously made that choice.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2976#issuecomment-14027248.

[wting]

Unfortunately I can't get my changes working. Once I bypass the bytecode check, ipython starts autoreloading system modules as well (e.g. os, sys, imp) causing this error:

In [2]: import foo
[autoreload of imp failed: Traceback (most recent call last):
  File "/home/ting/.virtualenvs/ipython/lib/python3.3/site-packages/ipython-1.0.dev-py3.3.egg/IPython/extensions/autoreload.py", line 231, in check
    superreload(m, reload, self.old_objects)
NameError: global name 'type' is not defined
]

Not exactly sure how to fix it so iPython only autoreloads modules imported after starting; open to any ideas.

[takluyver]

You could try sys.builtin_module_names. Doesn't autoreload already have some kind of blacklist?

[wting]

Doesn't work because there are other modules imported by IPython not in sys before loading, hence the max recursion depth error:

In [1]: import foo
[autoreload of urllib.parse failed: Traceback (most recent call last):
  File "/home/ting/.virtualenvs/ipython/lib/python3.3/site-packages/ipython-1.0.dev-py3.3.egg/IPython/extensions/autoreload.py", line 234, in check
    superreload(m, reload, self.old_objects)
RuntimeError: maximum recursion depth exceeded
]

[ellisonbg]

@takluyver what is the status of this one?

[takluyver]

The underlying problem is now tracked as #4127.