Hi Matt, Thanks for sharing your workflow. Here are some comments:
For #1 (remember where the function comes from -- yb), I find it important > to remember what the module has the function. I wouldn't want to get *os.path > *confused with *foorbar.null.path. *When I don't like the extra typing I > use the idiom *"from foobar import null as fbn"* and then use it as > *"fbn.path".* > My plan is that the programmer explicitly declares where functions are imported from --- but he does this only for external dependencies and only once per project. Imports for all python files will be built from these definitions. The rules are: * If you define a class, function or global variable `path` in your project --- then any undefined use of a name `path` will be provided with an automatic matching import statement. * The first time I want to use an external dependency (e.g. `Pathlib.path`) I have to define the corresponding import statement. * However, you can reuse this definition for all python files in this project --- and copy your favorite definitions in bulk to other projects. * If there is any conflict --- multiple definitions for the same name --- then you get an error message. You will have to decide on a unique name to feature map of names that you want to use in this project. As a result, there will be no ambiguity. For #2 and thus #3 (move the import statement to the top -- yb): just skip > them! When I'm in flow and need a new module I just "import foo" right > where I am, inside the function even. Later, after the thing is working > well enough, I move the import where it belongs. There are probably subtle > (or not so subtle!) scenarios where this pattern causes problems but so far > it hasn't happened to me. > Here is a problem with automatically moving import out of the body of functions or methods to the top of the file: When you have cyclic data dependencies between classes, you can resolve them by putting some import statements inside functions and not at the top of the file. These imports will be executed at run time (when the function is actually called) and hence break the import cycle. I came across a few special cases where swapping import statements with other statements can cause problems: * If a statement affects the import mechanism (such as setting the search path for modules) then it has to come before the imports. * gevent.monkey_patch() needs to run before other imports --- otherwise it won't work as intended. I'm not arguing against an auto-import feature, just answering the "what do > you do?" part of the question. > That's understood --- I appreciate the discussion. I saw a python utilty somewhere on pypi.org that handled > move-imports-automatically as part of a code linting process but didn't > feel the need to follow up on it. I see an active feature request for Black > to move and order imports: https://github.com/psf/black/issues/333. A > quick read of the comments seems to indicate it might be forthcoming soon. > If it does, then I expect Leo to be able to use it straightforwardly. > The 'optimize imports' feature of PyCharm (taken as a motivating example of this issue 333) does not move imports past function definitions. It only optimizes contiguous runs of import statements --- for the sake of correctness. -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAHWiE3X-YnjcD%2BgsjBAQsaw4Rdz2i%2BC%2Bs2OdabZSjGkz9QZv-Q%40mail.gmail.com.
