Re: Style question: Importing modules from packages - 'from' vs 'as'
On 12/03/2014 12:02 PM, 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? One argument not yet brought up by anyone else: if you ever wanted to make the module part of your own package and turn the import into a relative one, only the second, but not the first form lets you replace the package name with . : from . import path (while import .path is a SyntaxError, so you'd need a slightly more complicated rewrite). Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
- Original Message - From: Chris Angelico ros...@gmail.com To: python-list@python.org Sent: Wednesday, 3 December, 2014 12:02:17 PM Subject: Style question: Importing modules from packages - 'from' vs 'as' 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? 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. :) Thoughts? ChrisA -- https://mail.python.org/mailman/listinfo/python-list I know you specifically stated you didn't want to do this but import os os.path.isfile() is the best option imo, especially from the reader point of view (Namespaces are one honking great idea). -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On 12/04/2014 09:36 AM, Jean-Michel Pichavant wrote: I know you specifically stated you didn't want to do this but import os os.path.isfile() is the best option imo, especially from the reader point of view (Namespaces are one honking great idea). But, Flat is better than nested ! ;) -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On 12/03/2014 03:02 AM, Chris Angelico wrote: 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? I recommend the one with less typing. ;) -- ~Ethan~ signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On Fri, Dec 5, 2014 at 4:36 AM, Jean-Michel Pichavant jeanmic...@sequans.com wrote: I know you specifically stated you didn't want to do this but import os os.path.isfile() is the best option imo, especially from the reader point of view (Namespaces are one honking great idea). With os.path it definitely is. With the actual code in question, it's a Python 2.7 project that mostly uses relative imports - inside package.module1 is import module2 etc - and I was writing an external script that calls on one of the modules. So it makes sense to reference it through the code the exact same way, as module.blah rather than package.module.blah. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On 04.12.2014 19:05, Chris Angelico wrote: With os.path it definitely is. With the actual code in question, it's a Python 2.7 project that mostly uses relative imports - inside package.module1 is import module2 etc - and I was writing an external script that calls on one of the modules. What ? I'm usually thinking Python 3 not 2 and I'm never sure which Python 2.x has backported which feature of 3, but I thought implicit relative imports like you seem to describe are not working in 2.7 ? Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de wrote: On 04.12.2014 19:05, Chris Angelico wrote: With os.path it definitely is. With the actual code in question, it's a Python 2.7 project that mostly uses relative imports - inside package.module1 is import module2 etc - and I was writing an external script that calls on one of the modules. What ? I'm usually thinking Python 3 not 2 and I'm never sure which Python 2.x has backported which feature of 3, but I thought implicit relative imports like you seem to describe are not working in 2.7 ? Hmm, I'm not sure, but certainly it does seem to work that way. Typing import foo from inside a package will import foo.py from the package directory. I haven't dug into the details of _why_, and if ever the project shifts to Python 3 (which I would like it to), we might have to change some of the import lines, but I'd still like to be able to reference foo.bar as meaning the bar top-level object in foo.py. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On 04.12.2014 22:30, Chris Angelico wrote: On Fri, Dec 5, 2014 at 7:56 AM, Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de wrote: On 04.12.2014 19:05, Chris Angelico wrote: With os.path it definitely is. With the actual code in question, it's a Python 2.7 project that mostly uses relative imports - inside package.module1 is import module2 etc - and I was writing an external script that calls on one of the modules. What ? I'm usually thinking Python 3 not 2 and I'm never sure which Python 2.x has backported which feature of 3, but I thought implicit relative imports like you seem to describe are not working in 2.7 ? Hmm, I'm not sure, but certainly it does seem to work that way. Typing import foo from inside a package will import foo.py from the package directory. I haven't dug into the details of _why_, and if ever the project shifts to Python 3 (which I would like it to), we might have to change some of the import lines, but I'd still like to be able to reference foo.bar as meaning the bar top-level object in foo.py. I checked what the docs say about this and it is totally confusing (at least me): https://docs.python.org/3/howto/pyporting.html#from-future-import-absolute-import says: from __future__ import absolute_import Implicit relative imports (e.g., importing spam.bacon from within spam.eggs with the statement import bacon) do not work in Python 3. This future statement moves away from that and allows the use of explicit relative imports (e.g., from . import bacon). In Python 2.5 you must use the __future__ statement to get to use explicit relative imports and prevent implicit ones. In Python 2.6 explicit relative imports are available without the statement, but you still want the __future__ statement to prevent implicit relative imports. In Python 2.7 the __future__ statement is not needed. In other words, unless you are only supporting Python 2.7 or a version earlier than Python 2.5, use this __future__ statement. which I read as there has been a stepwise transition between 2.5 and 2.7 so that 2.7 now behaves like Python 3 even without the __future__ statement. OTOH, I believe you, of course, if you're saying implicit relative imports are working just fine in 2.7, but then how to interpret the In Python 2.7 the __future__ statement is not needed. above ? Wolfgang -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On Fri, Dec 5, 2014 at 9:10 AM, Wolfgang Maier wolfgang.ma...@biologie.uni-freiburg.de wrote: which I read as there has been a stepwise transition between 2.5 and 2.7 so that 2.7 now behaves like Python 3 even without the __future__ statement. OTOH, I believe you, of course, if you're saying implicit relative imports are working just fine in 2.7, but then how to interpret the In Python 2.7 the __future__ statement is not needed. above ? Hmm. To be honest, I'm not sure. The Python 2.7 __future__ module claims that absolute_import became standard in 3.0, not 2.7, which seems to conflict with what you're seeing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On 3 December 2014 at 22:02, Chris Angelico ros...@gmail.com wrote: import os.path as path from os import path Bah - deleted the list and sent directly to Chris ... time to go to bed. The advantage of the former is that if you want to use a different name, it's a smaller change. But the disadvantage of the former is that if you *don't* want to rename, it violates DRY (don't repeat yourself). The difference is so marginal that I'd leave it to personal preference, and wouldn't pull someone up for either in a code review. Tim Delaney -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
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. -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten __pete...@web.de wrote: 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. Thanks, Peter and Tim. Keeping DRY is worth doing (the more so as it's raining as I type this...), and I won't be renaming in this, so the from-import wins - but as Tim says, it's a close race. I do like the turn-around times on this list. Although, of course, it's entirely possible there'll be a week's worth of posts coming when someone hits on a controversial subaspect of the question somewhere; any volunteers? :) :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On Dec 3, 2014 4:34 AM, Chris Angelico ros...@gmail.com wrote: On Wed, Dec 3, 2014 at 10:27 PM, Peter Otten __pete...@web.de wrote: 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. Thanks, Peter and Tim. Keeping DRY is worth doing (the more so as it's raining as I type this...), and I won't be renaming in this, so the from-import wins - but as Tim says, it's a close race. To offer a counterpoint, the from import is also less explicit. With import os.path as path, path must be a module. With the from import, path could be either a module or just any attribute of the os module. My preference when importing modules is to use the fully qualified name -- os.path, not path. If I do a submodule import, I'm probably assigning a local name anyway, so I still prefer the import as over the from import as. -- https://mail.python.org/mailman/listinfo/python-list
Re: Style question: Importing modules from packages - 'from' vs 'as'
On 12/3/2014 6:02 AM, 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? I confirmed that they do the same thing for submodules. import os.path as pth from os import path pth module 'ntpath' from 'C:\\Programs\\Python34\\lib\\ntpath.py' path module 'ntpath' from 'C:\\Programs\\Python34\\lib\\ntpath.py' id(pth) 4319096 id(path) 4319096 I and most code I have seen uses from tkinter import ttk. 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. import tkinter.ttk as ttk makes it clear that ttk is a module rather than, say, a class. That might make things easier for the reader. On the other hand, duplication implies that there might be a real renaming, so having to compare to see that there is not, is extra work. from idlelib import EditorWindow import idlelib.EditorWindow as EditorWindow -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
