Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #20004 > unrolled thread

Re: when to use import statements in the header, when to use import statements in the blocks where they are used?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: when to use import statements in the header, when to use import statements in the blocks where they are used? Dave Angel <d@davea.name> - 2012-02-07 21:41 -0500
    Re: when to use import statements in the header, when to use import statements in the blocks where they are used? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-02-09 03:32 +0000

#20004 — Re: when to use import statements in the header, when to use import statements in the blocks where they are used?

You forgot to include the list in your reply, so I'm forwarding it for 
you.   One way you could have done it was to reply-all.


On 02/07/2012 09:32 PM, Patto wrote:
> Dave Angel：
>
> On Wed, Feb 8, 2012 at 10:05 AM, Dave Angel<d@davea.name>  wrote:
>
>> On 02/07/2012 08:48 PM, Lei Cheng wrote:
>>
>>> Hi all,
>>>
>>>     In a py file, when to use import statements in the header, when to use
>>> import statements in the blocks where they are used?
>>>     What are the best practices?
>>>     Thanks!
>>>
>>> Pat
>>>
>>>   Best practice is to put all the imports at the beginning of the module,
>> so they are easy to spot.
>>
>> If you put an import inside a function, it gets re-executed each time the
>> function is called, which is a waste of time.  Not too much, since import
>> first checks sys.modules to see if it's already loaded.
>>
>> Also, avoid the     from xxx import *    form, as it pollutes the
>> namespace.  And it makes it hard to figure out where a particular name is
>> declared.
>>
>> I believe these and other best practices can be found in pep8.
>>
>> http://www.python.org/dev/**peps/pep-0008/<http://www.python.org/dev/peps/pep-0008/>
>>
>> --
>>
>> DaveA
>>
>>
> yeah, I read pep8.
> However I find in the file path/to/djcelery/loaders.py from django-celery
> source, there are so many import/from statements used inside functions, I
> do not know why the author coded like this. Are there any special facts?
>

I can't speak for django or django-celery.  There are people that 
disagree on this, and there are some reasons to override the ones I 
mentioned.  One would be large modules that are not used in most 
circumstances, or not used till the program has run for a while.

If you put the import inside a function, you can save on startup time by 
deferring some of the logic till later.  And if there's a module that 
probably won't be used at all (eg. an error handler), perhaps you can 
avoid loading it at all.

I still think readability trumps all the other reasons, for nearly all 
programs.  Only once you decide you have a performance problem should 
you change that.

-- 

DaveA

[toc] | [next] | [standalone]

#20042

On Tue, 07 Feb 2012 21:41:49 -0500, Dave Angel wrote:

> On 02/07/2012 09:32 PM, Patto wrote:

>> However I find in the file path/to/djcelery/loaders.py from
>> django-celery source, there are so many import/from statements used
>> inside functions, I do not know why the author coded like this. Are
>> there any special facts?
>>
>>
> I can't speak for django or django-celery.  There are people that
> disagree on this, and there are some reasons to override the ones I
> mentioned.  One would be large modules that are not used in most
> circumstances, or not used till the program has run for a while.
> 
> If you put the import inside a function, you can save on startup time by
> deferring some of the logic till later.  And if there's a module that
> probably won't be used at all (eg. an error handler), perhaps you can
> avoid loading it at all.

Yes, the idea is "lazy importing" -- add the module name to the namespace, 
but don't actually load it until necessary. Apparently it is used heavily 
in Django and by PyPy.

Interestingly, the CPython developers are currently migrating the low-
level import machinery from C to pure Python (or at least mostly pure 
Python), because

(1) the C code is a mess and practically nobody understands it; 
(2) the exact import behaviour is very hard to explain; 
(3) consequently Jython, IronPython etc. may behave slightly differently;
(4) and they'd like to share the same code base as CPython; and
(5) it's really hard to write custom importers.

Moving to a pure Python implementation should fix these problems, 
provided that the speed hit isn't too big.

http://sayspy.blogspot.com.au/2012/02/how-i-bootstrapped-importlib.html


One suggestion made is that Python should support lazy imports out of the 
box.

Another reason for putting imports inside a function is that global 
imports are, well, global. If you only need access to a module from one 
function, why pollute the global namespace?

A reason for *not* importing inside a function is that there can 
sometimes be strange effects with threads, or so I've been told, but I 
couldn't begin to explain exactly what (allegedly) can go wrong.


> I still think readability trumps all the other reasons, for nearly all 
> programs.

Which is a good reason for importing inside a function: why confuse the 
reader with a global import if it isn't needed globally?



-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web