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


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

Re: Style question: Importing modules from packages - 'from' vs 'as'

Started byPeter Otten <__peter__@web.de>
First post2014-12-03 12:27 +0100
Last post2014-12-03 12:27 +0100
Articles 1 — 1 participant

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: Style question: Importing modules from packages - 'from' vs 'as' Peter Otten <__peter__@web.de> - 2014-12-03 12:27 +0100

#81853 — Re: Style question: Importing modules from packages - 'from' vs 'as'

FromPeter Otten <__peter__@web.de>
Date2014-12-03 12:27 +0100
SubjectRe: Style question: Importing modules from packages - 'from' vs 'as'
Message-ID<mailman.16528.1417606042.18130.python-list@python.org>
Chris Angelico wrote:

> When importing a module from a subpackage, it's sometimes convenient
> to refer to it throughout the code with a one-part name rather than
> two. I'm going to use 'os.path' for the examples, but my actual
> use-case is a custom package where the package name is, in the
> application, quite superfluous.
> 
> Throughout the code, I want to refer to "path.split()",
> "path.isfile()", etc, without the "os." in front of them. I could do
> either of these:
> 
> import os.path as path
> from os import path
> 
> Which one would you recommend? Does it depend on context?

Don't repeat yourself, so

from os import path

always. On the other hand I have never thought about actual renames, e. g.

from os import path as stdpath

versus

import os.path as stdpath

I think I'd use the latter as it looks simpler.

> An "as" import works only if it's a module in a package, where the
> "from" import can also import other objects (you can't go "import
> pprint.pprint as pprint"). I'm fairly sure that's an argument... on
> one side or another. :)

In theory you could sometimes catch erroneous assumptions about 
pprint.pprint's type. But I don't care.

[toc] | [standalone]


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


csiph-web