I'm still relatively inexperienced in Python, so I choose not to look at the source code for PyDev to figure out how the code completion functionality precisely works. From the FAQ I gather that it (by default) statically analyzes the source code and only starts up a Python shell for configured forced built-in libraries. However, I'm still left wondering why the following code completion doesn't work (and perhaps more importantly how I could get it to work):
import Ft.Xml # the 4suite XML etc. library
document = Ft.Xml.Parse(...) # ... being an URI to an XML file
document. # doesn't complete
Note that initially not even Ft.Xml shows up in the code completion. Adding Ft, Ft.Xml as forced built-in libraries at least makes it display some variables/functions/modules etc. but it's still quite limited. For example it doesn't complete:
document.xpath # it doesn't know about xpath
Did I by any chance overlook a somewhat more detailed explanation on the website for how code completion works and the associated quirks? For example, IPython's code completion functionality in this case works just fine (same for the included interactive console) and even using dir() on the result of Ft.Xml.Parse (an Ft.Xml.cDomlette.Document object) shows the xpath method.
I'm assuming that in this case the fact that it's using a module/extension (cDomlette) written in in C might have something to do with it?
Ok, the problem is that Ft.Xml.Parse() is a method (and not a class), so, as python does not have type info, pydev doesn't know the possible type returns of the Parse() method. It does try to get into that method to check for a direct return for that class, but that may not be actually statically available.
I think that in this situation, the only way to make it have code-completion would be adding a line such as
assert isinstance(document, ExpectedClass)
and the code-completion should be available for that.
That's mostly a limitation when analyzing python code, and until now I haven't seen a way to overcome it.
As for having 'Ft' and 'Ft.Xml' to the forced builtins is a valid customization to force it to gather some tokens from dynamically analyzing the module from a shell (but in the case of the Parse(), it won't actually execute the Parse() method, it'll only see the type of dir(Parse) -- which is a method and not a class, so, the tokens are actually unavailable -- actually executing dir(Parse()) would be too insecure to actually be feasible -- imagine that you could have a method 'deltree' that it would call to know the results for code-completion).
Thanks for taking the time to explain the problem here, it's quite clear to me now. You're also absolutely right that one does not want to execute code automatically for the purpose of code completion (and not just from a security point of view), here obviously lies the difference between the way IPython (and other shells) do code completion (the statement has already been executed).
I hope you don't mind though if I present the following possibility for code analysis that happened to cross my mind (most likely you have already thought about this yourself). Eventually the user will execute the code. Would it somehow be possible at that time to analyze the different variables etc. that have been created and cache that information for the purposes of code completion?
Looking forward to hearing you response.
Thanks for all your hard work.