I have the following imports
import time
import os
import daemon
When I click Code -> Optimize Imports in PyCharm I expect it to follow PEP 8 Imports Conventions (which should result in swapping time and os).
But what I get is the following:
import time
import daemon
import os
As you can see, PyCharm treats os module as if it was a third party module. This behavior was noticed in 2017.1 and 2017.3 versions of Pycharm.
Is this still the case in 2018.1? Or may it be some configuration problem?
Related
According to the official documentation, os.path is a module. Thus, what is the preferred way of importing it?
# Should I always import it explicitly?
import os.path
Or...
# Is importing os enough?
import os
Please DON'T answer "importing os works for me". I know, it works for me too right now (as of Python 2.6). What I want to know is any official recommendation about this issue. So, if you answer this question, please post your references.
os.path works in a funny way. It looks like os should be a package with a submodule path, but in reality os is a normal module that does magic with sys.modules to inject os.path. Here's what happens:
When Python starts up, it loads a bunch of modules into sys.modules. They aren't bound to any names in your script, but you can access the already-created modules when you import them in some way.
sys.modules is a dict in which modules are cached. When you import a module, if it already has been imported somewhere, it gets the instance stored in sys.modules.
os is among the modules that are loaded when Python starts up. It assigns its path attribute to an os-specific path module.
It injects sys.modules['os.path'] = path so that you're able to do "import os.path" as though it was a submodule.
I tend to think of os.path as a module I want to use rather than a thing in the os module, so even though it's not really a submodule of a package called os, I import it sort of like it is one and I always do import os.path. This is consistent with how os.path is documented.
Incidentally, this sort of structure leads to a lot of Python programmers' early confusion about modules and packages and code organization, I think. This is really for two reasons
If you think of os as a package and know that you can do import os and have access to the submodule os.path, you may be surprised later when you can't do import twisted and automatically access twisted.spread without importing it.
It is confusing that os.name is a normal thing, a string, and os.path is a module. I always structure my packages with empty __init__.py files so that at the same level I always have one type of thing: a module/package or other stuff. Several big Python projects take this approach, which tends to make more structured code.
As per PEP-20 by Tim Peters, "Explicit is better than implicit" and "Readability counts". If all you need from the os module is under os.path, import os.path would be more explicit and let others know what you really care about.
Likewise, PEP-20 also says "Simple is better than complex", so if you also need stuff that resides under the more-general os umbrella, import os would be preferred.
Definitive answer: import os and use os.path. do not import os.path directly.
From the documentation of the module itself:
>>> import os
>>> help(os.path)
...
Instead of importing this module directly, import os and refer to
this module as os.path. The "os.path" name is an alias for this
module on Posix systems; on other systems (e.g. Mac, Windows),
os.path provides the same operations in a manner specific to that
platform, and is an alias to another module (e.g. macpath, ntpath).
...
Interestingly enough, importing os.path will import all of os. try the following in the interactive prompt:
import os.path
dir(os)
The result will be the same as if you just imported os. This is because os.path will refer to a different module based on which operating system you have, so python will import os to determine which module to load for path.
reference
With some modules, saying import foo will not expose foo.bar, so I guess it really depends the design of the specific module.
In general, just importing the explicit modules you need should be marginally faster. On my machine:
import os.path: 7.54285810068e-06 seconds
import os: 9.21904878972e-06 seconds
These times are close enough to be fairly negligible. Your program may need to use other modules from os either now or at a later time, so usually it makes sense just to sacrifice the two microseconds and use import os to avoid this error at a later time. I usually side with just importing os as a whole, but can see why some would prefer import os.path to technically be more efficient and convey to readers of the code that that is the only part of the os module that will need to be used. It essentially boils down to a style question in my mind.
Common sense works here: os is a module, and os.path is a module, too. So just import the module you want to use:
If you want to use functionalities in the os module, then import os.
If you want to use functionalities in the os.path module, then import os.path.
If you want to use functionalities in both modules, then import both modules:
import os
import os.path
For reference:
Lib/idlelib/rpc.py uses os and imports os.
Lib/idlelib/idle.py uses os.path and imports os.path.
Lib/ensurepip/init.py uses both and imports both.
Couldn't find any definitive reference, but I see that the example code for os.walk uses os.path but only imports os
I wrote a GUI, for which I used these imports:
import os
import sys
import serial
import scipy
import string
import time
import datetime
import numpy as np
import matplotlib.pyplot as plt
import matplotlib as mpl
from collections import deque
from numpy import array
from pylab import xlabel, ylabel, subplot
from scipy.fftpack import fft
from pylab import *
There is a red line below sys and time, I am using pycharm community edition 4.5.3, it is showing the reason for this error is 'no module named sys' and same for time.
But when i tried to run it, it works perfectly.
What is the reason behind it and will it affect my code in future?
Change the python interpreter from python to python2.7. It's helped me.
This is something I just ran into with Intellij 2017.3.4 where it could find every module except sys and time in the editor, but everything would run fine. I had both 2.7 and 3.5 version of python and it did not seem to matter which one I selected as the SDK. I tried adding and removing them.
When I went to Project Structure -> Platform Settings -> SDKs -> Python 3.5 -> Packages it prompted a warning that Python packaging tools not found. and had an install link. I installed it and the editor no longer complained about sys and time. When I switched SDKs to 2.7 (without installing the packaging tools) it complained again.
So I am not exactly sure what is happening that that seemed to fix it for me it other people run into this problem.
I was having issues getting the scikit-learn module to import into python. It would import into the python shell, but not when I did it through my IDE. After reading lots of things online, I got it to work by using:
import sys
sys.path.append(r"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages")
import sklearn
Does anyone have a suggestion so that I don't need to do the sys thing every time I want to use the module?
In your IDE, find where you can change the "Python interpreter" setting, and point it to /Library/Frameworks/Python.framework/Versions/2.7/bin/python
I am trying to build an exe using PyInstaller (with Python 2.7) and have been stumped. My python code uses the modules wx, matplotlib, basemap (a part of matplotlib), and pylab. There are others, but these seem to be the main ones.
I have installed PyInstaller and then i did:
python pyinstaller.py C:/Python27/Convertthisfile.py
It goes through the whole process, but when i try to run the final executable, it comes up with the error:
"No module named PyQt4.QtCore"
I have installed PyQt GPL 4.9.1 for Python 2.7. However, I have no idea where PyQt is even being used in my code. I don't specify it anywhere that i know of.
Anyone have any thoughts? Nothing I do seems to work. I have even tried the GUI2EXE.py -- i can't get py2exe, pyinstaller, or cx_freeze to work.
HELP!
I have added my code below to hopefully help. To answer the comments, yes, my code is located in C:\Python27. I have no problem "building" it with pyinstaller, but the above error comes up when i try to run the given executable. I have searched the code and do not see any use of PyQt4.
When i run cx_freeze, i have issues with the basemap data files -- they do not seem to be included in the ".zip" when i build it. Also, none of my modules seem to get included either.
Here is what i import for my code (some of these functions are my own -- mainly the last ones listed).
import wx
import time
from matplotlib.backends.backend_wx import FigureCanvasWx as FigureCanvas
from mpl_toolkits.basemap import Basemap
from matplotlib.figure import Figure
from datetime import datetime
import wx.calendar as cal
import wx.lib.mixins.listctrl as listmix
from pylab import *
from decimal import *
import adodbapi
import annote_new
import cPickle as pickle
import calc_dist
import Game_Score
import Calculate_Distance
import Duplicate_Finder
import copy
Hopefully this clears things up?
According to the official documentation, os.path is a module. Thus, what is the preferred way of importing it?
# Should I always import it explicitly?
import os.path
Or...
# Is importing os enough?
import os
Please DON'T answer "importing os works for me". I know, it works for me too right now (as of Python 2.6). What I want to know is any official recommendation about this issue. So, if you answer this question, please post your references.
os.path works in a funny way. It looks like os should be a package with a submodule path, but in reality os is a normal module that does magic with sys.modules to inject os.path. Here's what happens:
When Python starts up, it loads a bunch of modules into sys.modules. They aren't bound to any names in your script, but you can access the already-created modules when you import them in some way.
sys.modules is a dict in which modules are cached. When you import a module, if it already has been imported somewhere, it gets the instance stored in sys.modules.
os is among the modules that are loaded when Python starts up. It assigns its path attribute to an os-specific path module.
It injects sys.modules['os.path'] = path so that you're able to do "import os.path" as though it was a submodule.
I tend to think of os.path as a module I want to use rather than a thing in the os module, so even though it's not really a submodule of a package called os, I import it sort of like it is one and I always do import os.path. This is consistent with how os.path is documented.
Incidentally, this sort of structure leads to a lot of Python programmers' early confusion about modules and packages and code organization, I think. This is really for two reasons
If you think of os as a package and know that you can do import os and have access to the submodule os.path, you may be surprised later when you can't do import twisted and automatically access twisted.spread without importing it.
It is confusing that os.name is a normal thing, a string, and os.path is a module. I always structure my packages with empty __init__.py files so that at the same level I always have one type of thing: a module/package or other stuff. Several big Python projects take this approach, which tends to make more structured code.
As per PEP-20 by Tim Peters, "Explicit is better than implicit" and "Readability counts". If all you need from the os module is under os.path, import os.path would be more explicit and let others know what you really care about.
Likewise, PEP-20 also says "Simple is better than complex", so if you also need stuff that resides under the more-general os umbrella, import os would be preferred.
Definitive answer: import os and use os.path. do not import os.path directly.
From the documentation of the module itself:
>>> import os
>>> help(os.path)
...
Instead of importing this module directly, import os and refer to
this module as os.path. The "os.path" name is an alias for this
module on Posix systems; on other systems (e.g. Mac, Windows),
os.path provides the same operations in a manner specific to that
platform, and is an alias to another module (e.g. macpath, ntpath).
...
Interestingly enough, importing os.path will import all of os. try the following in the interactive prompt:
import os.path
dir(os)
The result will be the same as if you just imported os. This is because os.path will refer to a different module based on which operating system you have, so python will import os to determine which module to load for path.
reference
With some modules, saying import foo will not expose foo.bar, so I guess it really depends the design of the specific module.
In general, just importing the explicit modules you need should be marginally faster. On my machine:
import os.path: 7.54285810068e-06 seconds
import os: 9.21904878972e-06 seconds
These times are close enough to be fairly negligible. Your program may need to use other modules from os either now or at a later time, so usually it makes sense just to sacrifice the two microseconds and use import os to avoid this error at a later time. I usually side with just importing os as a whole, but can see why some would prefer import os.path to technically be more efficient and convey to readers of the code that that is the only part of the os module that will need to be used. It essentially boils down to a style question in my mind.
Common sense works here: os is a module, and os.path is a module, too. So just import the module you want to use:
If you want to use functionalities in the os module, then import os.
If you want to use functionalities in the os.path module, then import os.path.
If you want to use functionalities in both modules, then import both modules:
import os
import os.path
For reference:
Lib/idlelib/rpc.py uses os and imports os.
Lib/idlelib/idle.py uses os.path and imports os.path.
Lib/ensurepip/init.py uses both and imports both.
Couldn't find any definitive reference, but I see that the example code for os.walk uses os.path but only imports os