Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Fully general code completion for Python isn't actually possible in an "offline" editor (as opposed to in an interactive Python shell).</p> <p>The reason is that Python is too dynamic; basically anything can change at any time. If I type <code>TypeA.Val</code> and ask for completions, the system had to know what object <code>TypeA</code> is bound to, what its class is, and what the attributes of both are. All 3 of those facts can change (and do; <code>TypeA</code> starts undefined and is only bound to an object at some specific point during program execution).</p> <p>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!</p> <p>So what pydev does instead is guess, when it's pretty obvious. If you have a class block in a module <code>foo</code> defining class <code>Bar</code>, then it's a safe bet that the name <code>Bar</code> imported from <code>foo</code> is going to refer to that class. And so you know something about what names are accessible under <code>Bar.</code>, or on an object created by <code>obj = Bar()</code>. Sure, the program <em>could</em> be rebinding <code>foo.Bar</code> (or altering its set of attributes) at runtime, or could be run in an environment where <code>import foo</code> is hitting some other file. But that sort of thing happens rarely, and the completions are useful in the common case.</p> <p>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 <code>TypeA</code> has names <code>ValOk</code> and <code>ValSomethingSpecificToThisClassWentWrong</code>; after all, there's presumably lots of other objects that result from calls to <code>TYPE_GEN</code>, but they all have different names.</p> <p>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 <code>"a": b,</code> per item rather than <code>a = b</code>. 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 <em>and</em> write than the dictionary driving <code>TYPE_GEN</code>.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload