'from X import a' versus 'import X; X.

2019-03-13 08:05发布

I've seen some Python programmers use the following style fairly consistently (we'll call it style 1):

import some_module
# Use some_module.some_identifier in various places.

For support of this style, you can cite the "explicit is better than implicit" maxim. I've seen other programmers use this style (style 2):

from some_module import some_identifier
# Use some_identifier in various places.

The primary benefit that I see in style 2 is maintainability -- especially with duck typing ideals I may want to swap some_module for some_other_module. I also feel style 2 wins points with the "readability counts" maxim. Although I tend to disagree, one can always argue that search-and-replace is just as good an option when using the first style.

Addendum: It was noted that you could use as to solve the switch from some_module to some_other_module in style 1. I forgot to mention that it is also common to decide to implement some_identifier in your current module, which makes creation of an equivalent some_module container slightly awkward.

9条回答
成全新的幸福
2楼-- · 2019-03-13 08:47

I personally try not to mess too much with my namespace, so in most situations I just do

import module  

or import module as mod

Only real diffrence is when I have a module with a single class that's used a lot. If I had sublclassed a list type to add some funcionality there, I'd use

from SuperImprovedListOverloadedWithFeatures import NewLIst
nl = NewList()

etc.

查看更多
趁早两清
3楼-- · 2019-03-13 08:49

I usually use a threshold to decide this. If I want to use a lot of things within some_module, I'll use:

import some_module as sm
x = sm.whatever

If there's only one or two things I need:

from some_module import whatever
x = whatever

That's assuming I don't need a whatever from some_other_module, of course.

I tend to use the as clause on the imports so that I can reduce my typing and substitue another module quite easily in the future.

查看更多
戒情不戒烟
4楼-- · 2019-03-13 08:54

I find that the notation

from some_module import some_symbol

works best in most cases. Also, in case of name clash for the symbol, you can use:

from some_module import some_symbol as other_symbol

As the question states, it avoids rewriting the module name all the time, each time with a risk of mistyping it. I use the syntax:

import  module [as other_module]

Only in two cases:

  1. I use too many of the module functions/objects to import them all
  2. The module defines some symbol that may change during execution
查看更多
女痞
5楼-- · 2019-03-13 08:55

I prefer to import X and then use X.a as much as possible.

My exception centers on the deeply nested modules in a big framework like Django. Their module names tend to get lengthy, and their examples all say from django.conf import settings to save you typing django.conf.settings.DEBUG everywhere.

If the module name is deeply nested, then the exception is to use from X.Y.Z import a.

查看更多
太酷不给撩
6楼-- · 2019-03-13 08:57

With the existence of the following syntax:

import some_other_module as some_module

the maintainability argument of style 2 is no longer relevant.

I tend to use style 1. Normally, I find that I explicitly reference the imported package name only a few times in a typical Python program. Everything else is methods on the object, which of course don't need to reference the imported package.

查看更多
手持菜刀,她持情操
7楼-- · 2019-03-13 09:02

There are uses for both cases, so I don't think this is an either-or issue. I'd consider using from module import x,y,z when:

  • There are a fairly small number of things to import

  • The purpose of the functions imported is obvious when divorced from the module name. If the names are fairly generic, they may clash with others and tell you little. eg. seeing remove tells you little, but os.remove will probably hint that you're dealing with files.

  • The names don't clash. Similar to the above, but more important. Never do something like:

     from os import open
    

import module [as renamed_module] has the advantage that it gives a bit more context about what is being called when you use it. It has the disadvantage that this is a bit more cluttered when the module isn't really giving more information, and is slightly less performant (2 lookups instead of 1).

It also has advantages when testing however (eg. replacing os.open with a mock object, without having to change every module), and should be used when using mutable modules, e.g.

import config
config.dburl = 'sqlite:///test.db'

If in doubt, I'd always go with the import module style.

查看更多
登录 后发表回答