##// END OF EJS Templates
Reset the interactive namespace __warningregistry__ before executing code...
Reset the interactive namespace __warningregistry__ before executing code Fixes #6611. Idea: Right now, people often don't see important warnings when running code in IPython, because (to a first approximation) any given warning will only issue once per session. Blink and you'll miss it! This is a very common contributor to confused emails to numpy-discussion. E.g.: In [5]: 1 / my_array_with_random_contents /home/njs/.user-python2.7-64bit-3/bin/ipython:1: RuntimeWarning: divide by zero encountered in divide #!/home/njs/.user-python2.7-64bit-3/bin/python Out[5]: array([ 1.77073316, -2.29765021, -2.01800811, ..., 1.13871243, -1.08302964, -8.6185091 ]) Oo, right, guess I gotta be careful of those zeros -- thanks, numpy, for giving me that warning! A few days later: In [592]: 1 / some_other_array Out[592]: array([ 3.07735763, 0.50769289, 0.83984078, ..., -0.67563917, -0.85736257, -1.36511271]) Oops, it turns out that this array had a zero in it too, and that's going to bite me later. But no warning this time! The effect of this commit is to make it so that warnings triggered by the code in cell 5 do *not* suppress warnings triggered by the code in cell 592. Note that this only applies to warnings triggered *directly* by code entered interactively -- if somepkg.foo() calls anotherpkg.bad_func() which issues a warning, then this warning will still only be displayed once, even if multiple cells call somepkg.foo(). But if cell 5 and cell 592 both call anotherpkg.bad_func() directly, then both will get warnings. (Important exception: if foo() is defined *interactively*, and calls anotherpkg.bad_func(), then every cell that calls foo() will display the warning again. This is unavoidable without fixes to CPython upstream.) Explanation: Python's warning system has some weird quirks. By default, it tries to suppress duplicate warnings, where "duplicate" means the same warning message triggered twice by the same line of code. This requires determining which line of code is responsible for triggering a warning, and this is controlled by the stacklevel= argument to warnings.warn. Basically, though, the idea is that if foo() calls bar() which calls baz() which calls some_deprecated_api(), then baz() will get counted as being "responsible", and the warning system will make a note that the usage of some_deprecated_api() inside baz() has already been warned about and doesn't need to be warned about again. So far so good. To accomplish this, obviously, there has to be a record of somewhere which line this was. You might think that this would be done by recording the filename:linenumber pair in a dict inside the warnings module, or something like that. You would be wrong. What actually happens is that the warnings module will use stack introspection to reach into baz()'s execution environment, create a global (module-level) variable there named __warningregistry__, and then, inside this dictionary, record just the line number. Basically, it assumes that any given module contains only one line 1, only one line 2, etc., so storing the filename is irrelevant. Obviously for interactive code this is totally wrong -- all cells share the same execution environment and global namespace, and they all contain a new line 1. Currently the warnings module treats these as if they were all the same line. In fact they are not the same line; once we have executed a given chunk of code, we will never see those particular lines again. As soon as a given chunk of code finishes executing, its line number labels become meaningless, and the corresponding warning registry entries become meaningless as well. Therefore, with this patch we delete the __warningregistry__ each time we execute a new block of code.

File last commit:

r16278:273703b8
r18548:61431d7d
Show More
README.rst
67 lines | 2.1 KiB | text/x-rst | RstLexer
Fernando Perez
Fix broken download URL for PyPI in setup call, minor readme updates.
r4459 ===========================================
IPython: Productive Interactive Computing
===========================================
fperez
Reorganized the directory for ipython/ to have its own dir, which is a bit...
r0
Brian E Granger
Cleaning up the IPython docs. I have removed old README files that were outdated and being maintained...
r1250 Overview
========
darren.dale
More testing Darren Dale user, test done still by fperez. Whitespace-only change.
r864
Fernando Perez
Minor doc updates, ensure README is in final tarball.
r6599 Welcome to IPython. Our full documentation is available on `our website
<http://ipython.org/documentation.html>`_; if you downloaded a built source
distribution the ``docs/source`` directory contains the plaintext version of
these manuals. If you have Sphinx installed, you can build them by typing
Aaron Meurer
Make it more clear in the README how exactly to build the docs
r7825 ``cd docs; make html`` for local browsing.
Brian Granger
Updated the main README.txt file to refect the 0.9 release.
r1719
Fernando Perez
Make it possible to run the tests from the source dir without installation....
r2481
Fernando Perez
Add a note about supported python versions to docs (and website)...
r2573 Dependencies and supported Python versions
==========================================
For full details, see the installation section of the manual. The basic parts
of IPython only need the Python standard library, but much of its more advanced
functionality requires extra packages.
MinRK
update README with dropped 2.6 and 3.2 support...
r12475 Officially, IPython requires Python version 2.7, or 3.3 and above.
IPython 1.x is the last IPython version to support Python 2.6 and 3.2.
Fernando Perez
Add a note about supported python versions to docs (and website)...
r2573
Aaron Meurer
Make it more clear in the README how exactly to build the docs
r7825
Fernando Perez
Remove stale reference to iptest.py top-level script.
r2536 Instant running
===============
Fernando Perez
Make it possible to run the tests from the source dir without installation....
r2481
You can run IPython from this directory without even installing it system-wide
MinRK
README.txt -> README.rst
r3345 by typing at the terminal::
Fernando Perez
Make it possible to run the tests from the source dir without installation....
r2481
MinRK
remove mention of `ipython.py` from README
r10575 $ python -m IPython
Dražen Lučanin
quick dev installation instructions
r10139
Development installation
========================
If you want to hack on certain parts, e.g. the IPython notebook, in a clean
environment (such as a virtualenv) you can use ``pip`` to grab the necessary
dependencies quickly::
MinRK
update README with dropped 2.6 and 3.2 support...
r12475 $ git clone --recursive https://github.com/ipython/ipython.git
$ cd ipython
Ezequiel (Zac) Panepucci
update install instructions to use --user for pip
r16278 $ pip install -e ".[notebook]" --user
Dražen Lučanin
quick dev installation instructions
r10139
This installs the necessary packages and symlinks IPython into your current
environment so that you can work on your local repo copy and run it from anywhere::
$ ipython notebook
Kyle Kelley
Added missing s
r10224 The same process applies for other parts, such as the qtconsole (the
Dražen Lučanin
quick dev installation instructions
r10139 ``extras_require`` attribute in the setup.py file lists all the possibilities).
MinRK
mention git hooks in top-level readme
r10558
Git Hooks and Submodules
************************
IPython now uses git submodules to ship its javascript dependencies.
If you run IPython from git master, you may need to update submodules once in a while with::
$ git submodule update
or::
$ python setup.py submodule
We have some git hooks for helping keep your submodules always in sync,
see our ``git-hooks`` directory for more info.