Well, I imagine one reason is that there are exactly zero static call sites in Python. Everything is called by name, and monkey-patching is, for better or worse, an accepted and widely used tactic. I have seen projects that use Python's source code introspection facility to rewrite code inside decorators. You can even define new keywords in this way.
Decorators in general are a widely used tactic to execute arbitrarily Python code with potentially unknown runtime state to transform the Python code you just parsed into a totally new function.
There is just very little you can learn from parsing Python code, you need runtime state to understand some functions. It is potentially as difficult as Lisp, and with a much larger set of primitives to cover.
And if you take the approach that you aren't going to just parse, you are going to implicitly execute the Python that is being written, then you need to sandbox the whole of Python. It's not like a REPL where everything is explicit and if a programmer writes subprocess.call(['rm', '-rf', '/']) they want their filesystem to blow up. You can't just go around implicitly executing WIP code.
Now, a reasonable approach might be to punt on the whole issue and say, "If your code doesn't execute in a vacuum, with standard python libraries and no funny business with decorators and monkey-patching, then we won't touch it" but I think the reality is that there is a lot of important Python code that can't be correct in such a vacuum.
It's not a total lost cause, but I do think there are many good reasons why a Python Light Table is very hard.
Monkey patching is NOT widely accepted in Python, just the opposite. For an example look at gevent, which is actually quite useful and elegant but often panned and avoided in the Python community because it works by monkey patching. The same attitude is not equally present in every dynamic language.
Where you are certainly right is that monkeypatching may occur in a project and this is only one of many ways that Python's being very dynamic makes it extra hard to write static analysis tools.
The rm -rf problem is not as bad if you are previewing (say) a page view, which hopefully is not being developed on a production server and hopefully doesn't contain an rm -rf. But I agree that solving this in the general case is probably intractable without some kind of container.
>Well, I imagine one reason is that there are exactly zero static call sites in Python.
Are there in Smalltalk?
>There is just very little you can learn from parsing Python code, you need runtime state to understand some functions. It is potentially as difficult as Lisp, and with a much larger set of primitives to cover.
Yes, but Clojure, a "Lisp", is supported no? If in that case it's the JVM that provides extra runtime intelligence, they could make it support Jython instead of CPython.
Decorators in general are a widely used tactic to execute arbitrarily Python code with potentially unknown runtime state to transform the Python code you just parsed into a totally new function.
There is just very little you can learn from parsing Python code, you need runtime state to understand some functions. It is potentially as difficult as Lisp, and with a much larger set of primitives to cover.
And if you take the approach that you aren't going to just parse, you are going to implicitly execute the Python that is being written, then you need to sandbox the whole of Python. It's not like a REPL where everything is explicit and if a programmer writes subprocess.call(['rm', '-rf', '/']) they want their filesystem to blow up. You can't just go around implicitly executing WIP code.
Now, a reasonable approach might be to punt on the whole issue and say, "If your code doesn't execute in a vacuum, with standard python libraries and no funny business with decorators and monkey-patching, then we won't touch it" but I think the reality is that there is a lot of important Python code that can't be correct in such a vacuum.
It's not a total lost cause, but I do think there are many good reasons why a Python Light Table is very hard.