Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #81853 > unrolled thread
| Started by | Peter Otten <__peter__@web.de> |
|---|---|
| First post | 2014-12-03 12:27 +0100 |
| Last post | 2014-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.
Re: Style question: Importing modules from packages - 'from' vs 'as' Peter Otten <__peter__@web.de> - 2014-12-03 12:27 +0100
| From | Peter Otten <__peter__@web.de> |
|---|---|
| Date | 2014-12-03 12:27 +0100 |
| Subject | Re: 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.
Back to top | Article view | comp.lang.python
csiph-web