Ipython: NumPy DeprecationWarning wird auf seltsame Weise gehandhabt

Erstellt am 6. Apr. 2018  ·  4Kommentare  ·  Quelle: ipython/ipython

Wenn eine Operation mit NumPy 1.14 ausgeführt wird, die veraltet zu sein scheint, scheint die Warnung je nach Kontext zu IPython oder dem IPython-Kernel zurückzuverfolgen, was etwas irreführend ist. Im Jupyter-Notizbuch fügt es einen kleinen zusätzlichen Text hinzu, der angibt, This is separate from the ipykernel package so we can avoid doing imports until und hört einfach so auf (daher wird hier zuerst erhöht). Ich bin mir nicht sicher, ob dies ein Problem in IPython, dem IPython-Kernel oder NumPy ist. Hier ist jedoch ein MRE.


Beispiel:

In [1]: import numpy as np

In [2]: a = np.arange(24).reshape(1, 2, 3, 4)

In [3]: np.expand_dims(a.min(), a.ndim)
/zopt/conda2/envs/test/bin/ipython:1: DeprecationWarning: Both axis > a.ndim and axis < -a.ndim - 1 are deprecated and will raise an AxisError in the future.
  #!/zopt/conda2/envs/test/bin/python
Out[3]: array([0])



Umfeld:

name: test
channels:
- conda-forge
- defaults
dependencies:
- appnope=0.1.0=py36_0
- backcall=0.1.0=py_0
- blas=1.1=openblas
- ca-certificates=2018.1.18=0
- certifi=2018.1.18=py36_0
- decorator=4.2.1=py36_0
- ipython=6.3.1=py36_0
- ipython_genutils=0.2.0=py36_0
- jedi=0.11.1=py36_0
- libgfortran=3.0.0=0
- ncurses=5.9=10
- numpy=1.14.2=py36_blas_openblas_200
- openblas=0.2.20=7
- openssl=1.0.2n=0
- parso=0.1.1=py_0
- pexpect=4.4.0=py36_0
- pickleshare=0.7.4=py36_0
- pip=9.0.3=py36_0
- prompt_toolkit=1.0.15=py36_0
- ptyprocess=0.5.2=py36_0
- pygments=2.2.0=py36_0
- python=3.6.5=1
- readline=7.0=0
- setuptools=39.0.1=py36_0
- simplegeneric=0.8.1=py36_0
- six=1.11.0=py36_1
- sqlite=3.20.1=2
- tk=8.6.7=0
- traitlets=4.3.2=py36_0
- wcwidth=0.1.7=py36_0
- wheel=0.31.0=py36_0
- xz=5.2.3=0
- zlib=1.2.11=0

Hilfreichster Kommentar

Eine PR, die ich an Python gesendet habe, wurde zusammengeführt, daher sollte dies in Python 3.8 behoben sein.

https://github.com/python/cpython/pull/6622

Alle 4 Kommentare

Ja, das ist das Ergebnis davon, dass __main__ zwei verschiedene Dinge darstellen. Es versucht, eine Warnung für Zeile 1 Ihres interaktiv eingegebenen Codes auszugeben, der als Teil des Moduls __main__ wird. Aber die Zeilen kommen von dem anderen __main__ -Modul – der Datei, die Python zum Starten von IPython oder zum Starten des Kernels ausgeführt hat. Der angezeigte Text ist also die erste Zeile dieser Datei (der Text This is separate... ist ein Dokumentstring).

Es ist ein bisschen chaotisch und verwirrend, aber es war nie wirklich ein Problem, das groß genug war, um es wert zu sein, behoben zu werden.

Ich wurde neugierig und ging, um zu sehen, was es braucht, um es zu reparieren. Wir könnten den Code ganz einfach aus allen Warnungen weglassen, die __main__ , aber das ist etwas unbefriedigend. Den richtigen Code anzuzeigen ist für IPython, soweit ich das beurteilen kann, unmöglich, da das Warnungsmodul Code in seiner eigenen eigentümlichen Sprache nachschlägt.

Tracebacks und pdb finden die Datei wie folgt:

frame.f_code.co_filename

Warnings findet die Datei wie folgt:

frame.f_globals.get('__file__', sys.argv[0])

Wir geben jeder Eingabe einen eindeutigen gefälschten Dateinamen für ihren Code, damit sie nach Rückverfolgungen durchsucht werden kann. Aber sie müssen sich alle den globalen Namensraum teilen, daher denke ich, dass wir sie im Moment nicht für Warnungen unterscheiden können. Ich habe dies gerade zu einem alten Python-Problem kommentiert.

Eine PR, die ich an Python gesendet habe, wurde zusammengeführt, daher sollte dies in Python 3.8 behoben sein.

https://github.com/python/cpython/pull/6622

Danke @takluyver!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen