##// END OF EJS Templates
upstream » ipython
RSS

Clone from https://github.com/ipython/ipython.git

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.
MinRK - - Load All Authors

File last commit:

r16141:8a7c5eab
r18548:61431d7d
Show More
COPYING.rst
74 lines | 3.3 KiB | text/x-rst | RstLexer
/ COPYING.rst
History | Source | Raw |Copy content |Copy permalink
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 =============================
The IPython licensing terms
=============================
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 IPython is licensed under the terms of the Modified BSD License (also known as
Jonathan Frederic
Update COPYING.txt...
 r15988 New or Revised or 3-Clause BSD), as follows:
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203
Jonathan Frederic
Update COPYING.txt...
 r15988 - Copyright (c) 2008-2014, IPython Development Team
- Copyright (c) 2001-2007, Fernando Perez <fernando.perez@colorado.edu>
- Copyright (c) 2001, Janko Hauser <jhauser@zscout.de>
- Copyright (c) 2001, Nathaniel Gray <n8gray@caltech.edu>
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
All rights reserved.
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 Redistributions in binary form must reproduce the above copyright notice, this
list of conditions and the following disclaimer in the documentation and/or
other materials provided with the distribution.
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 Neither the name of the IPython Development Team nor the names of its
contributors may be used to endorse or promote products derived from this
software without specific prior written permission.
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
About the IPython Development Team
----------------------------------
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 Fernando Perez began IPython in 2001 based on code from Janko Hauser
<jhauser@zscout.de> and Nathaniel Gray <n8gray@caltech.edu>. Fernando is still
the project lead.
The IPython Development Team is the set of all contributors to the IPython
project. This includes all of the IPython subprojects. A full list with
details is kept in the documentation directory, in the file
``about/credits.txt``.
Brian E Granger
Cleaning up the IPython docs. I have removed old README files that were outdated and being maintained...
 r1250
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 The core team that coordinates development on GitHub can be found here:
Jonathan Frederic
Update COPYING.txt...
 r15988 https://github.com/ipython/.
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
Our Copyright Policy
--------------------
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 IPython uses a shared copyright model. Each contributor maintains copyright
over their contributions to IPython. But, it is important to note that these
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249 contributions are typically only changes to the repositories. Thus, the IPython
source code, in its entirety is not the copyright of any single person or
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 institution. Instead, it is the collective copyright of the entire IPython
Development Team. If individual contributors want to maintain a record of what
changes/contributions they have specific copyright on, they should indicate
their copyright in the commit message of the change, when they commit the
change to one of the IPython repositories.
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
Jonathan Frederic
Update COPYING.txt...
 r15988 With this in mind, the following banner should be used in any source code file
Fernando Perez
Reflow license file and update with link to Github IPython org page.
 r3203 to indicate the copyright and license terms:
Brian E Granger
Creating new COPYING.txt that is copied over from ipython1-dev.
 r1249
Jonathan Frederic
Update COPYING.txt...
 r15988 ::
MinRK
remove weird unicode space in the new copyright header...
 r16141 # Copyright (c) IPython Development Team.
# Distributed under the terms of the Modified BSD License.