[wingide-users] Working with frameworks that dynamically import
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.
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...
Wingware | Python IDE
The Intelligent Development Environment for Python Programmers
More information about the wingide-users