Fully general code completion for Python isn't actually possible in an "offline" editor (as opposed to in an interactive Python shell).
The reason is that Python is too dynamic; basically anything can change at any time. If I type TypeA.Val
and ask for completions, the system had to know what object TypeA
is bound to, what its class is, and what the attributes of both are. All 3 of those facts can change (and do; TypeA
starts undefined and is only bound to an object at some specific point during program execution).
So the system would have to know st what point in the program run do you want the completions from? And even if there were some unambiguous way of specifying that, there's no general way to know what the state of everything in the program is like at that point without actually running it to that point, which you probably don't want your editor to do!
So what pydev does instead is guess, when it's pretty obvious. If you have a class block in a module foo
defining class Bar
, then it's a safe bet that the name Bar
imported from foo
is going to refer to that class. And so you know something about what names are accessible under Bar.
, or on an object created by obj = Bar()
. Sure, the program could be rebinding foo.Bar
(or altering its set of attributes) at runtime, or could be run in an environment where import foo
is hitting some other file. But that sort of thing happens rarely, and the completions are useful in the common case.
What that means though is that you basically lose completions whenever you use "too much" of Python's dynamic language flexibility. Defining a class by calling a function is one of those cases. It's not ready to guess that TypeA
has names ValOk
and ValSomethingSpecificToThisClassWentWrong
; after all, there's presumably lots of other objects that result from calls to TYPE_GEN
, but they all have different names.
So if your main goal is to have completions, I think you'll have to make it easy for pydev and write these classes out in full. Of course, you could use similar code to generate the python files (textually) if you wanted. It looks though like there's actually more "syntactic overhead" of defining these with dictionaries than as a class, though; you're writing "a": b,
per item rather than a = b
. Unless you can generate these more systematically or parse existing definition files or something, I think I'd find the static class definition easier to read and write than the dictionary driving TYPE_GEN
.