2017-12-05 1 views
2

Wenn ich den Python läuft interpretter innerhalb lldb versuchen, ich sehe:merkwürdige Vermischung von System + Homebrew Python mit LLDB

$ lldb 
(lldb) script 
Traceback (most recent call last): 
    File "<input>", line 1, in <module> 
    File "/usr/local/Cellar/python/2.7.14/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 52, in <module> 
    import weakref 
    File "/usr/local/Cellar/python/2.7.14/Frameworks/Python.framework/Versions/2.7/lib/python2.7/weakref.py", line 14, in <module> 
    from _weakref import (
ImportError: cannot import name _remove_dead_weakref 
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. 

Wenn ich prüfe, welche Version von Python ins Leben gerufen wurde, berichtet Python, dass es sein sollte sein der Homebrew Python (die in diesen Ort Symlink ist):

>>> sys.executable 
'/usr/local/opt/python/bin/python2.7' 

jedoch die Python-Version fragen, die Version mit dem Standard System Python-Installation zugeordnet gibt, zB

>>> sys.version_info 
sys.version_info(major=2, minor=7, micro=10, releaselevel='final', serial=0) 

Und nur um zu bestätigen, die Python-Version auf dem binären Pfad oben ist in der Tat anders (man beachte den Unterschied in der Mikro-Version):

$ /usr/local/opt/python/bin/python2.7 --version 
Python 2.7.14 

$ /usr/bin/python --version 
Python 2.7.10 

Um die Dinge noch verwirrender zu machen, wird der Name _remove_dead_weakreftut gibt es in dem _weakref Modul für meine Homebrew Python-Installation, aber nicht die Standard-Systeminstallation:

$ /usr/bin/python -c "import _weakref; print _weakref._remove_dead_weakref" 
Traceback (most recent call last): 
    File "<string>", line 1, in <module> 
AttributeError: 'module' object has no attribute '_remove_dead_weakref' 

$ /usr/local/opt/python/bin/python2.7 -c "import _weakref; print _weakref._remove_dead_weakref" 
<built-in function _remove_dead_weakref> 

Irgendeine Idee, was dieses offensichtliche Übersprechen zwischen meinen Python-Installationen mit LLDB verursachen könnte? Wie kann ich das verhindern?

+1

scheint dies in 10.13.3 behoben worden, lldb wird immer System Python Binär-und Bibliothek verwenden. – georgexsh

+0

Leider sehe ich immer noch das gleiche Problem auf macOS 10.13.3. –

Antwort

2

Eine Problemumgehung für dieses Problem besteht darin, LLDB explizit mit der System-Python-Installation auf dem PATH zu starten, z.

PATH=/usr/bin /usr/bin/lldb 

Es scheint, als ob LLDB die PATH für die 'aktive' Python-Installation abfragt; Wenn Sie eine Homebrew-Installation von Python auf der PATH haben, dann können Sie in diese Art von Nebensprechen geraten, wenn LLDB versucht, Python zu starten.

+0

Ich schaute durch die Quellen, um zu sehen, wo wir das tun könnten, und ich kann nirgends finden, wo wir Python speziell initialisieren. Dies könnte in Python unter der Haube passieren? Es ist alles hier getan: http://llvm.org/svn/llvm-project/lldb/trunk/source/Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.cpp in InitializePythonRAII, wenn es irgendwelche Python-Experten gibt, die eine haben wollen schau, ob wir das falsch machen. –