Hi Toshio On Wed, Feb 16, 2011 at 2:05 AM, Toshio Kuratomi <[email protected]> wrote:
> On Mon, Feb 14, 2011 at 05:27:44PM +0100, Arve Knudsen wrote: > > Does it matter in practice how many times a module gets imported locally > to a > > function though? I find that in certain cases I have to defer importing > of > > certain modules until they are used, so it's not just a matter of style. > I > > don't think pylint should by default warn about local imports, that's > just way > > too strict unless there's some good reason I'm unaware of. > > > Someone else already posted the stylistic reasons not to do this (and for > those alone, I think pylint is right to have a message for this). There's > also an efficiency reason. If you have a function that gets called > repeatedly and it's doing a reimport, the import machinery does cause a > slow > down (even though python discovers that the module has already been > imported > and skips some of the steps.) > First of all, does pylint really have a message for this? The current pylint version issues a reimport warning, which does not quite fit this case (I see this warning as a way to reduce clutter by removing duplicate imports). If pylint really were to see local imports as a style violation, there should be a specific warning for it so you can treat it differently from static reimports. Anyway, this behaviour is apparently already recognized as a bug, since monsieur Thenault requested I file a ticket on it. Regarding optimization, don't you know that premature optimization is evil? Unless optimization efforts actually prove beneficial, you're wasting time on details. Besides, if you want optimization advice are you sure that a *linter* is the right tool? A linter, to be truly useful, has to straddle the line between too forgiving and too strict; if pylint by default were to decide that I am breaking good style by importing within functions, I'd see it as going way overboard as to its practical purpose (and perhaps question its place in my tool chain). It might make sense, on the other hand, as a non-default check (maybe custom) for those projects that view the practice as a problem. Arve
_______________________________________________ Python-Projects mailing list [email protected] http://lists.logilab.org/mailman/listinfo/python-projects
