Develop Reference

How do I reset the python build system in Sublime Text 3 on WIndows 10?

I've deinstalled and reinstalled a bunch of Python Versions and edited my system variables in order to clean up the quagmire of pip not being able to install packages to the right locations. Long story short: Sublime now can't find numpy (or any 3rd party module), because it somehow figured that the python 2.3 version that comes with ChemDraw is the one I really want to use, not the 3.9 version I had used previously.
I've tried a bunch of tutorials online (such as resetting everything to factory settings) however nothing seems to unlink the python build system from that python 2.3 version that came with ChemDraw. Even deinstalling everything and installing Sublime 4 keeps that association. Like...how?
So here's my problem: My build system for python is linked to the wrong python version and I don't know how to link it to the python 3.9 that's located in AppData/Programs.
How can I associate the python.exe of python 3.9 in AppData with my python Build System instead of the current python 2.3, which is located ProgramFiles?

Ok, so the problem was that there was a system variable called PYTHONPATH, which I don't remember setting. It seems that Chemdraw, if installed with ChemScript, installs it's own python installation, which is 2.X.
That python install seems to set its own system variable called PYTHONPATH, which Sublime seems to prioritize for it's default python build system.
Delete whatever incorrect path is set in PYTHONPATH and paste the following into it instead:
C:...\Python\Python39\Scripts;C:...\Python\Python39;C:...\Python\Launcher;

Should a virtualenv have it's own "argparse"?

I have a virtual environment, that's used by multiple people on multiple machines. I ran into a problem today that a user couldn't import argparse.
The problem ended up being that I am running python2.7.10_2 and he is running 2.7.13. The python in the virtualenv, is mine, so 2.7.10_2. This meant that it was looking for system libraries in the wrong place (/usr/local/Cellar/python/2.7.10_2, instead of 2.7.13/) However, I thought that the point of virtual environments is that all of the libraries are in the venv, and so it doesn't matter what versions of python you actually have installed anywhere.
However, it seems that there is no argparse in venv/lib/site-packages, and so it uses my original PYTHONPATH, which isn't correct for the user.
For other reasons, the virtualenv was originally created with the relocatable flag, so that isn't the problem.
ETA:
The solution I came up with (hideous kludge though it is) Is that I had the user symlink 2.7.13 to 2.7.10_2, so it can find his original libraries.

System Python conflict between Anaconda and existing Python installation

I've been going with a basic Python3.4 install that I've been installing many modules into for over the past month but have reached a point where pip is coming up short and I'm going to just install the full Anaconda on my system to go deeper into bokeh-server stuff.
I get a popup during the Windows 64bit installer (Anaconda3-2.3.0-Windows-x86_64.exe) saying
A version of Python 3.4 (64-bit) is already at C:\Python34\ We
recommend that if you want Anaconda registered as your system Python,
you unregister this Python first. If you really know this is what you
want, click OK, otherwise click cancel to continue.
Didn't find much documentation on this subject, and I'm not really sure how to "unregister" that installation of Python apart from uninstalling it entirely from Windows which I imagine would accomplish such a thing. Is this basically telling me to check how my Python Launcher for Windows is setup after the Anaconda installation? I'm completely unfamiliar with this notion of python system registration? Is that just a round about warning about which python version takes precedence on the system path, or which installation holds the file associations?

The solution is simply to uninstall python (for example, run the original python installer and select the uninstall option). The python key in the windows registry will be removed (which is what unregister means in this context).

Here is a link to a script that will unregister a Python installation (if you haven't come across it already). I personally have not dealt with anything like this. It seems like it should work, but you may have to tinker around with some of the paths in the script to get things to work. The links in #nightuser 's post will also probably fix the issue.
Why not just remove your version of Python? You could do a pip freeze > requirements.txt with your current Python and add them to Anaconda, or create an environment with Anaconda using those packages. Anaconda has greatly decreased the amount of time I spend setting things up.

You are getting that prompt because you have another version already installed the safe way to do this is going to the directory of the existing version and running the uninstaller. Once the previous version is completely uninstalled. You can run the installation as normal it should works!

enter image description hereYou have already installed python in your environment, so your system can handle your python code. Anaconda can handle your python code as well. If you install Anaconda and expect use python provided by Anaconda, then your system will confuse about assigning the code job. To avoid this confusion, there is always a path to point out which python you want.
You can ask your OS to find specific python by changing your environment path in windows OS:
By deleting the python path your Python will be invisible. Changing path is more convenient compared with the uninstall.
If you got a python compiling software like Pycharm, things are different. Pycharm may have python3.6 while your system got python 3.5. You need to delete path in those software or uninstall python specified by those software.
Pycharm
Actually, instead of registering the Anaconda as the system python, you can install it first, then specify your Pycharm and system path to the Anaconda python path. Thus, your Pycharm will use python provided by Anaconda and package & virtual environment you need.
I edit this for lots of times because I got Great wall, so I can't close something pop up in my screen(cause it is Blank). And everything is missing if I refresh. This is annoying.
My system path Anaconda3's python36
Add path in Pycharm
Or you can't use these packages and Anacon's virtual Environment

Multiple Versions of Python on my Windows machine: Which is the "right" one?

In continuing to research a solution for this question on ServerFault:
https://serverfault.com/questions/221203/mercurial-hook-fails-on-windows
I discovered an interesting and somewhat disturbing thing: I have seem three different versions of Python on my machine (four if you count the "official" version which doesn't appear to have a DLL with it....). Here's shot from my file search tool:
More Info:
I am running Windows 7 64-bit
Both the TortoiseHG and the Mercurial directories are on my path, with the Mercurial directory listed first.
I have Python 2.6 installed in c:\Python26
I have no entry for any type of PYTHON-based environmental variable. (Should I?)
I suspect that this is the source of the my problem from the question above, but I thought I'd ask here, as this is particular issue is a Python deal.
I tried to replace both DLLs with each other, but when I use the one that comes with Mercurial, then TortoiseHg stops working.
It seems to me that "there should only be one" Python on my machine. How do I achieve that?

For the problem that you mentioned earlier, the mercurial package got installed within python under mercurial home but you are executing scripts under C:\python26. So you need to install and execute your script under mercurial python
As seth mentioned earlier it is perfectly ok to multiple python homes in the same machine but you just to pay attention when installing python libraries to make sure that you are under the right home which means you set the path right before calling python.

Side note: The Python installation in "C:\Python26" installs its DLL to the Windows directory, in your case "C:\Windows\SysWOW64".
Answering your serverfault question: As you installed Mercurial as standalone version, you'll have to place any packages that are accessed by hooks into Mercurial's library folder (if it has one, could also be "library.zip").
I would recommend you to uninstall the Mercurial standalone version and instead install Mercurial with pip. This makes updates easier and you can use your normal "site-packages" directory for both normal Python libraries and hg hooks.

I would assume that tortoise/mercurial have just embedded their own versions of python to do whatever they need to do.
I wouldn't worry about it, the DLLs won't stomp on each other -- the PATH is the last placed that windows searches to find DLLs.
See: http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx

Each DLL is for that application. There is only one in your search path so you don't need to worry about conflicts.
Is something not working that prompted you to worry about this??
Your assumption that there should only be one is wrong, each application has bundled a specific version with a fixed API, you can't just drop another in and hope it'll work.

The Python DLL naming structure only provides the major version and revision numbers. You are probably looking at the DLLs for versions 2.6.1, 2.6.4, 2.6.5, and 2.6.6.
All of this doesn't really matter as long as each application contains its own copy of the python26.dll. Windows will not explore the PATH environment variable if there is a local copy of the file.

Is it possible to install python 3 and 2.6 on same PC?

How would I do this? The reason being I wanted to try some pygame out, but I have python 3 installed currently and have been learning with that. I'm also interested in trying out wxpython or something like that, but I haven't looked at their compatibilities yet.
EDIT:: im on a windows vista 64-bit

If you are on Windows, then just install another version of Python using the installer. It would be installed into another directory.
Then if you install other packages using the installer, it would ask you for which python installation to apply. If you use installation from source or easy_install, then just make sure that when you install, you are using the one of the proper version.
If you have many packages installed in your current python-3, then just make a zip backup of your current installation just in case.

Erm... yes. I just installed Python 3.0 on this computer to test it. You haven't specified your operating system, but I'm running Ubuntu 9.04 and I can explicitly specify the version of Python I want to run by typing python2.5 myscript.py or python3.0 myscript.py, depending on my needs.

Typically python is installed with a name like python2.6, so you can have more than one. There may be a symlink from python to one of the numbered files. Quite workable.

Yes, it is possible.
I maintain 3 python installations (2.5, 2.6, 3.0). The only issue that could be confusing is figuring out which Python version takes precedence in PATH variable (if any) . To execute a script for a specific version, you would go into the python directory for that version
C:\Python25\ , C:\Python26\, C:\Python30\, etc.
Drop the file in there, and run "python.exe file.py" from command-line.
You could even rename each python.exe to python25.exe python26.exe python30.exe and have each directory in PATH so it would be easy to execute any script on any version.

I would assume it'd be the same as running two versions of 2.x; as long as they're each in their own directory you should be OK.

You certainly can. On Mac Ports, there's a tool called python_select that lets you switch among python versions; if nothing like it exists on Windows (momentary googling didn't reveal one), it could certainly be written.

You can set up virtual python environments using virtualenv.