The 3.6 installer suggests C:\Users\MyUserName\AppData\Local\Programs\Python\Python36-32 which is unlike any other software on Windows.
I remember that earlier versions installed to C:\PythonXY which is also unusual on Windows. Is any of that really a good idea?
In particular, I don't see why I would want to install this only for my user account. The checkbox "Install launcher for all users (recommended)" is default checked which seems incompatible with installing into %APPDATA%.
What is a good path to install Python to?
I'm a complete Python amateur and I don't want to cause myself problems. I am fearful of adding a space to the path for example.
Clicking further through the installer it turns out there is a checkbox to install for all users. This immediately sets a Program Files (x86) based path to the checkbox.
This is a very subjective question in most cases, I'm not really sure if its even fit for SO.
Here are the different characteristics of each path:
C:\PythonXY:
Requires administrator rights
All users have access to it - better if you want only one install of a python version on your system
More practical to write in command line (might be needed for multiple python installs, although using venvs or conda envs solves this problem)
Program Files is the same, except that there are spaces in the path (probably a bad idea)
AppData:
Doesn't require administrator rights
Only for one user - good if the other users don't want/need it
Might be painful to write in command line
I have admin rights and am the only user on my computer, so I chose the first option, but it really is case-dependent.
EDIT Please see the comments below for rectifications on paths.
Installing Python in c:\Program Files\ in 64-bit Windows 10 has problems because of the new "security features" of Windows 10. Subfolders of c:\Programs Files\ have restricted permissions on them which are not compatible with the installation processes for some Python packages. Installing in a directory directly below the root (for example c:\Python36\ for Python 3.6) avoids these problems. It may be "less secure", but it actually works, which installing under c:\Program Files\ sometimes does not. For example, I have found that if you try to install the matplotlib package in Python 3.7 installed under c:\Program Files\, some of the packages that matplotlib is dependent on are blocked from installing, and the package will not run, but if it is installed in c:\Python37\, it runs fine. Another example of overly enthusiastic Microsoft "security."
Installing in the %appdata% folder for a single user is fine if you are the only person who is going to be using Python, but if your computer is going to be used by another user (for example, if it is a work computer which will be "inherited" by a new employee that takes over your position), Python (and all necessary Python packages) would have to be reinstalled for that user.
I think the best path to install python is in C:\Users\<Username>\PythonXX (especially if you are using PC with multiple users and also if you are using your organization PC.
If you install to C:\PythonXX or to C:\Program Files\PythonXX, you will always have permissions issue. As soon as you try to install some packages/libraries using 'pip install ', permissions will not allow to install the packages.
If you leave the installation to be continued in C:\Users\<Username>\AppData\Local\Programs\Python\PythonXX as suggested by python installer, which also doesn't have any permissions issue, but path is not so easy to remember.
Few more important points:
If you are using a personal laptop and you are the only user (you will be administrator as well), then installing python to C:\PythonXX is also a best option.
Always check the option, add python path to Path variable during installation, so that you can also use python from command prompt/powershell.
Always check the option, install pip, so that you can use pip to install/update packages/libraries.
In my case because the Path variable was already set, I would only go to the python shell and type:
import os
os.path
Related
Short description: two computers in the same network, in the new one only those python scripts work that use native packages.
I have Pycharm in my old computer and it has worked fine. Now I got a new computer, installed the most recent version of Python and Pycharm, then opened one of my old projects. Both the old and the new computer are in the same network and the project is on a shared folder. So I did the following:
File - Open - selected the project. Got a message that there is no interpreter
Add local interpreter - selected the latest Python 311 exe. So location of the venv is the same as in the old computer (because it's a network folder) but Base interpreter is pointing to the C drive of my new computer.
PyCharm creates a virtual environment and the code runs fine.
I select another project which uses imported packages such as pandas. Again, same steps as above, add local interpreter. Venv is created.
I go to File - Setting - Project and see that pip, setuptools and wheel are listed as Packages. If I double click one of these, I can re-install and get a note that installation is succesful, so nothing seems to be wrong in the connection (after all, both the old and the new computer are in the same network.
I click the plus sign to add a new one, search pandas. Installation fails. Same thing if I try e.g. numpy.
Error message has lots of retrying, then "could not find the version that satisfies the requirement pandas (from versions: none", "not matching distribution found for pandas" (pip etc. have the latest versions).
After few hours of googling for solutions, I have tried the following:
Complety uninstall and reinstall python and PyCharm. Checked that PATH was included in the installation.
Tried launching pip command from shell
Changed http proxy to auto-detect
Typed 'import pandas' in PyCharm, then used the dropdown in the yellow bulb but there is no install option
Started a new project in the new computer, tried to install pandas
All failed. I'm surprised that changing computers is this difficult. Please let me know if there are other options than staying in the old computer...
If you want to use venv in the network, please use SSH interpreter. Pycharm supports this method. Shared folders are not a recommended usage, For pycharm, it will consider this as a local file. If the file map is not downloaded locally, it will make an error.
Another way is to reinstall the project environment on the new computer through requirement.txt. Reasonable use of requirements.txt can effectively avoid many project bugs caused by environment migration or different dependent versions. Before installing some scientific module such as pandas, it is recommended to install visual studio build tools, such as gcc ...
This took a while but here is what happened. Package installation did not work in project settings. Neither did it work when you select Python Packages tab at the bottom of the screen. The only thing that worked was to select the Terminal tab and manually install (pip install) there. We use a trusted repository but for other users, the easier package installation methods work. Not sure why they do not for me but at least there is this manual workaround.
I've installed anaconda, but I still want to use python as normal within a Terminal window (zsh). At the moment, running which python shows /Users/USERNAME/opt/anaconda3/bin/python.
I don't want this command to point to my anaconda installation. I want to use python as I have in the past, and for it to point to my python 2.7 installation (/usr/bin/python).
The same issue is present with pip and with python3. How do I change these paths back to their default locations?
I want to start out by saying I personally have never used Anaconda, but I have many friends who have and they always seem to wind up getting into hot water as far as configurations go. If you don't need the data-science specific tools that Anaconda offers (most of which I imagine you can get just as easily by using pip install <package_name>), then I STRONGLY urge you to not use Anaconda. I would suggest you instead use homebrew to install python 3.7 and leave the system version of python 2.7 alone... Anyways...
I recently fixed an issue similar to the one you're describing for a friend. I ended up deleted his anacaonda build and reinstalling fresh from homebrew (link: https://brew.sh/), so this is how I helped him and hopefully this will help you too.
Firstly, I would check the configuration of your ~/.bash_profile (or potentially ~/.bashrc) file. Comment out any lines you find that have to do with Anaconda by preceding with the # character. I believe when anaconda installs it puts the location of the anaconda-version-of-python higher in the PATH hierarchy, therefore you computer sees it first before it has the chance to look in /usr/bin...
Secondly, you need to move the anaconda-python to the trash... I would start by trashing the whole '/Users/USERNAME/opt/anaconda3' directory. If memory serves me correctly anaconda stores other python related things in the /MacitoshHD/Library/Frameworks directory, but don't quote me on that. I would advise looking there and trashing whatever seems to be related to the anaconda install.
After that, in a new terminal (so that your PATH refreshes), I installed homebrew, and then ran the command brew install python3 to install python3. I think perhaps I ran the command recommended in the installer output, something like "brew link python3" to symlink python3 where it needs to be linked after the installation.
Finally, everything is done python2 and python3 are installed and working with no issues. python2 is the system default version and python3 is the homebrew installed version. Feel free to ask any questions and I will try to help more, hopefully those instructions will get you started though.
I thought it is an easy question but I spent a lot of google time to find the answer with no luck. Hope you can help me.
My company has a large SW system on windows which is portable, meaning copy some folders, add some folder to windows path and you are ready to go.
No registry, no dll in system directory, no shortcuts, Nothing!
I want to start using python 3.x in our system in the same paradigm. I also want the ability to add to this distribution a pip/conda 3rd packages from time to time.
I don't want to install python msi on all the systems.
I don't want to pack it to standalone executable like py2exe and pyinstaller or use special python distribution like PyWin32.
Somehow, I couldn't find a formal official solution for that.
The closest thing was here but no pip is supported, python is minimal, and the system isolation is "almost".
3.8. Embedded Distribution New in version 3.5.
The embedded distribution is a ZIP file containing a minimal Python
environment. It is intended for acting as part of another application,
rather than being directly accessed by end-users.
When extracted, the embedded distribution is (almost) fully isolated
from the user’s system, including environment variables, system
registry settings, and installed packages. The standard library is
included as pre-compiled and optimized .pyc files in a ZIP, and
python3.dll, python36.dll, python.exe and pythonw.exe are all
provided. Tcl/tk (including all dependants, such as Idle), pip and the
Python documentation are not included.
Note The embedded distribution does not include the Microsoft C
Runtime and it is the responsibility of the application installer to
provide this. The runtime may have already been installed on a user’s
system previously or automatically via Windows Update, and can be
detected by finding ucrtbase.dll in the system directory. Third-party
packages should be installed by the application installer alongside
the embedded distribution. Using pip to manage dependencies as for a
regular Python installation is not supported with this distribution,
though with some care it may be possible to include and use pip for
automatic updates. In general, third-party packages should be treated
as part of the application (“vendoring”) so that the developer can
ensure compatibility with newer versions before providing updates to
users.
Any ideas?
Thanks.
How about... installing Python in one machine and replicate that installation on others computers?
Usually, I install Python in a Windows Virtualbox machine (Microsoft usually give it for free to try it or for testing old Internet Explorer versions).
Then I copy the Python directory to my Windows machine (the real host) and usually works. This makes possible to using various python versions.
Did you try to complete the Python Embedded Distribution? Usually they not come with Tkinter, but once I could copy files and put in this distribution in a way that works. Try it too.
You can install pip with get-pip.py
I have recently been learning Python 3. I have had no problems on my netbook (32bit Windows 7) I with creating small simple programs. When I installed it on my netbook I had no problems, but now that I've been getting into it I want to install it on my desktop and I have one.
My desktop is a 64 bit OS running Windows 7. Like I did with my netbook, I went to download Python and install the 64 bit edition.
After installing it, I went to open up Python CLI and GUI and no luck. It gave me this error.
"The application was unable to start correctly (0xc000007b). Click OK to close the application"
I also tried reinstalling, but not luck.
I suspect a missing .dll but I am not completely sure. Does anyone know what is keeping me from opening Python and how do I fix it?. I want to resume my work as soon as possible.
That is the NTSTATUS error code for STATUS_INVALID_IMAGE_FORMAT. Almost invariably that means that the loaded is attempting to link a 32 bit DLL into a 64 bit process, or vice versa.
If you want to attempt to debug this then the tool of choice is Dependency Walker. You open the python.exe executable file in Dependency Walker and use the profile menu to start it up with logging of the load events. Somewhere along the way there will be a failure and you'll be able to see which module is causing that failure. That will hopefully point the way towards a resolution.
However, attempting to debug this may be a waste of time. It will probably better to uninstall the existing installation, and try to re-install. Perhaps picking a different Python distribution.
I note that you have selected a 64 bit version. Now, support for 64 bit extension modules is not as strong on 64 bit Python as on 32 bit Python. It does exist, but they modules can be harder to come by and install. You might consider installing a 32 bit Python next time round.
Please make sure that Python3.dll is the same version and the same architecture (32/64) with python.exe. I fixed this error via replacing it with 32bit version.
you should delete the old path of python in "Environment Variables" and enjoy ;)
As janne-karila mentioned, and for Python 3.5, Microsoft Visual Studio 2015 redistributable (in this case the 64 bit version)
This probably won't answer your question, but my answer is for a very specific case when you "Refresh Windows without affecting Files" to fix your Windows 8.1 PC.
If you do that, You'd get this error when you try to run Python after the windows refresh.
To fix this error, simply re-install PY at the same folder where your python was install before you refreshed windows. If you try to install it any other folder like username/appdata/... folder the PY installer would be stuck in initialization.
You may also get another error saying "api-ms-win-crt-runtime-l1-1-0.dll is missing". To fix, go to the windows.old folder and get the dll file ith the above name and paste it in the PY folder. Also like others have suggested, make sure Microsoft Visual Studio 2015 redistributable is installed.
Encountering this error after a windows refresh is so rare, that no one else seemed to have experienced according to google searches, so I though I share it here for that rare unlucky person.
Apparently the error code stands for STATUS_INVALID_IMAGE_FORMAT (source), and it looks like it's not specific to Python. You can try reinstalling the program, rebooting, running CHKDSK /r (source). It might also have something to do with the Microsoft Visual C++ redistributable package, as Janne Karila and this thread suggest.
This stackoverflow question also looks like it has some useful information.
I too faced this problem. So I uninstalled python3 64-bit version and installed 32-bit version, after that i am able to launch python3 in windows 8 successfully. (i have a 64-bit laptop).
Simply, download the last version of Microsoft Visual C++ redistributable package ..
I had the same problem ..
I have the same error found. Using dependency walker, I found tons of DLLs missing. Rather going for copying all the DLLs I went with virtual environment. It will create another environment for Python.
First, install python normally. Copy, the Python.exe path. In my case, it is
C:\Python\python
It will be used to install Python libraries. Then, using command prompt, I used pip to download and install virtualenv (Virtual environment). To do that, change the directory to where pip.exe is, which is in Scripts folder. Now, run the following to install virtualenv:
C:\Python\python pip install virtualenv
It will install Virtual environment.
Now, create a folder to hold virtual environment and change directory to that folder and run to create the following to create an environment:
virtualenv --no-site-packages [environment name]
It will create the Environment.
Now, change subdirectory to Scripts in the [environment name] folder. There is a activate file run it, in my case it is like:
C:\Python\virtualenv\env\Scripts activate
env is the [environment name] here.
If you activate it, every command will look like:
(env) C:\Python\python
This ends here. Now, you can install any python library using this. Do whatever, you want using Python.
Also, to deactivate the environment same deactivate.bat is in the scripts folder.
For me the issue was, I had installed 32 bit version on a 64 bit machine. Hope it helps someone out there.
Like many have said, Windows cannot load python.exe itself or one of its dependent DLLs because of INVALID_IMAGE_FORMAT:
python.exe is of unsupported bitness. 32bit on 64bit Windows is supported. 64bit on 32bit system is not (solution: install 32bit python, bye).
python.exe or one of its DLLs is corrupted (probably not)
one of the dependent DLLs is not of the same bitness as the EXE:
python.exe (say, 32bit) requires python*.dll (python3.dll or python27.dll). It installs that into Windows System32/SysWOW64 folder. The DLL is of correct bitness (32bit).
Something else overwrites that with 64-bit version, or places a 64-bit version somewhere in the search PATH.
When you run python.exe (32bit), Windows searches for python*.dll, and the first one it founds is the 64bit one. 32bit EXEs cannot normally load 64bit DLLs.
Typical examples:
TortoiseHg installs its own copy of python (both .exe and .dll) into its own folder and adds itself to PATH. The bitness can be different (say, 64bit) and usually matches platform bitness.
Another installation of Python with a different bitness somewhere else overwrites the DLL (it shouldn't, they have different System32s, but who knows)
Diagnostics:
Dependency Walker marks 64bit DLLs with 64bit icons. Verify that icons for python.exe and python*.dll match. Right click -> "Show full paths" to see where the DLL is taken from.
Simple solutions:
Maybe you have another, functioning copy of Python somewhere else? Check it.
Reinstall Python, preferably in the platform version (64bit for 64bit OS, 32bit for 32bit) Yeah, that's what many are saying, but now you know why this is needed.
Remove offenders from PATH. While this maaaay fix your Python, this will break the offenders and some (TortoiseHg explorer plugins) need the PATH. So maybe compromise with them and choose #2.
In my case I was installing both the 32 and 64 bit versions of the python msi. They both install to the same folder, c:\python32. I thought msi's would prevent those kinds of conflicts, but no.
I'm currently doing some embedded systems programming. This was set up by somebody else a few years ago. So now I'm looking to upgrade to Python 2.7.2 to make things simpler because I have already run into two cases where what I coded wasn't supported.
What is currently running:
: uname -a
Linux host1 2.6.18-6-486 #1 Sun Feb 10 22:06:33 UTC 2008 i586 GNU/Linux
: python -v
Python 2.4.4
: pyversions -i
python2.4
So right now only 2.4 is installed.
I untarred python2.7.2 and when I go to that directory and run python27 setup.py install --home=/home/jhemilian and it seems like python2.4 doesn't seem to know the with...as statement syntax:
host1:/home/jhemilian/src/Python-2.7.2: python setup.py install --home=/home/jhe
milian
File "setup.py", line 361
with open(tmpfile) as fp:
^
SyntaxError: invalid syntax
Before I go figuring this out I first have a question: python itself is being used to install Python? What if I didn't have the first version of Python installed? I know it's shipped with most Linux but hypothetically -- how does such a seeming catch-22 like that work?
What I am looking to do is install python2.7 in a benign location, keeping the python command still as using Python 2.4 just in case the "legacy" software i'm running is dependent on it, and running python2.7 myscript.py et cetera when I want to run one of my newer scripts. Feel free to comment if there is a cleaner or more practical (or even safer!) way to do this.
I don't think it would make much sense to go replacing all the with statements with compatible try blocks. I've looked though the READMEs and online documentation but I can't seem to find a way to install Python without already having Python. Note that I DO NOT have internet connection, although if desirable or necessary I could. It would be great if somebody could point me in the right direction. Thanks!!
It's all right in the README...
You don't need to use python to install, in fact, you shouldn't...just:
./configure
make
make install
If you want to install in a specific dir, just follow what the README says:
Installing
To install the Python binary, library modules, shared library modules
(see below), include files, configuration files, and the manual page,
just type
make install
This will install all platform-independent files in subdirectories of
the directory given with the --prefix option to configure or to the
prefix' Make variable (default /usr/local). All binary and other
platform-specific files will be installed in subdirectories if the
directory given by --exec-prefix or theexec_prefix' Make variable
(defaults to the --prefix directory) is given.
If DESTDIR is set, it will be taken as the root directory of the
installation, and files will be installed into $(DESTDIR)$(prefix),
$(DESTDIR)$(exec_prefix), etc.
All subdirectories created will have Python's version number in their
name, e.g. the library modules are installed in
"/usr/local/lib/python/" by default, where is the
. release number (e.g. "2.1"). The Python binary is
installed as "python" and a hard link named "python" is
created. The only file not installed with a version number in its
name is the manual page, installed as "/usr/local/man/man1/python.1"
by default.
If you want to install multiple versions of Python see the section
below entitled "Installing multiple versions".
The only thing you may have to install manually is the Python mode for
Emacs found in Misc/python-mode.el. (But then again, more recent
versions of Emacs may already have it.) Follow the instructions that
came with Emacs for installation of site-specific files.
EDIT: virtualenv is apparently for already-installed Python versions. Disregard this recommendation.
I think what you want is virtualenv.
I haven't used it myself, but I understand this is what it's meant for.
From the website:
virtualenv is a tool to create isolated Python environments.
The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform's standard location is), it's easy to end up in a situation where you unintentionally upgrade an application that shouldn't be upgraded.
EDIT: Upon review, I think you want Alberto's answer, so I voted him up for visibility.