[wingide-users] Working with frameworks that dynamically import

Wingware Support support at wingware.com
Thu Dec 18 11:06:25 EST 2014

Joshua J. Kugler via wingide-users wrote:
>> One way to work around this is to run to a breakpoint and then edit.
>> >  When the debugger is active, Wing uses both live runtime state and
>> >  static analysis to fill the auto-completer, source assistant, etc.  This
>> >  is my preferred way to work, for more reasons than just working around
>> >  limitations in static analysis.  You can also immediately try things out
>> >  in the live runtime state using the Debug Probe.
> That might work for already-imported items, so I might try that. However, I
> have tried that, basically. I execute run.py, and even in the context of my
> views.py, it still cannot find the types, even though views.py has been
> imported in the Flask init process. Maybe I would need to run views.py as the
> file I execute. The other problem I see: even if I get the types from already
> imported objects, I still can't get a drop down for:
> from flask.ext import ...

You do need to run to a breakpoint in the code where you plan to edit, 
so it's on the stack.  But as you noted already this won't solve 
completion at | in "from flask.ext import |".

> Another idea I thought of was this: The custom importer that is triggered by
> "from flask.ext import" is this:
> ExtensionImporter(['flask_%s', 'flaskext.%s'], __name__)
> According to the docs, it does this:
> """
> When a user does ``from flask.ext.foo import bar`` it will attempt to import
> ``from flask_foo import bar``
> """
> Is there a way to tell Wing to
> 1) Have wing rifle though all modules it finds of pattern flask_* and look for
> importable objects; and
> 2) recognize the 'from flask.ext.foo import bar' pattern and turn it into
> 'from flask_foo import bar' for the Source Assistant's benefit?

Neither of these are supported now.  The second one may be something we 
should add for cases like this.

However, from 
http://flask.pocoo.org/docs/0.10/extensiondev/#ext-import-transition it 
sounds like the flask.ext form of import is a transitional hack to allow 
extensions to move away from the old namespace approach without 
affecting users (because those users may end up with a mix of old or new 
packaging for extensions on different installations).

This seems to imply that "from flask_foo import bar" is a valid way to 
import an extension that's completed the transition to the new model.

For that reason I'd probably just use that and not go through all the 
trouble of working around the import hackery.

The only case where you would run into trouble doing that would be if 
you distribute your code and some users end up having versions of the 
extensions that are still packaged in the old way.  But this seems 
unlikely since presumably you don't want people using your code with 
extensions older than the ones you developed with.

I hope this is helpful...


Stephan Deibel
Wingware | Python IDE

The Intelligent Development Environment for Python Programmers


More information about the wingide-users mailing list