Why would a Python import succeed when invoking *.py file from python but not when invoked by file name alone

Question

I'm in the early stages of integrating some Python to invoke some computations in Matlab and roll up all the figures into some html generation I'll be doing in ll.xist. I had initially installed Python 2.7.5 32bit, but with a 64bit Matlab R2015a installation I could not install the matlab engine for that version of python. I then downloaded a 64bit version of Python 2.7.9 and tried to do a pip into ll-xist, which was apparently not well maintained and failed. I then downloaded Python 3.4.3 64bit, downloaded the ll.xist installer ll-xist-5.13.win-amd64-py3.4.exe and thought I was good to go. I had to do a pip to pull in cssutils, which succeeded.

Now I come to the point where I invoke my python file from the console. If I invoke it preceded with python everything works fine, if I don't the import isn't recognized . What could account for that discrepancy? Looks like some installation snafu between the various versions I've installed, somehow the python version on the path isn't being called appropriately and I'm guessing the 2.7.9 version of python is being invoked somehow because that install never had ll.xist installed, though my 2.7.5 install did.

C:\Temp>python MyScript.py a.txt b.txt
  file1: a.txt
  file2: b.txt

C:\Temp>MyScript.py a.txt b.txt
Traceback (most recent call last):
  File "C:\Temp\MyScript.py", line 20, in <module>
    from ll.xist    import xsc
ImportError: No module named ll.xist

Here's a sanity check too...

C:\Temp>python
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

C:\Temp>which python
/cygdrive/c/Python34/python

Answer 1

Check the file association for .py. While the proper installation might be in your path, the file association might still be pointing to a different version.

You can check this by importing the sys module in a test script and call print(sys.version) . Then run the test script with python test.py and just test.py to see which versions are printed.

Answer 2

Turns out the governing issue here is what is known as the Python Launcher for Windows .

3.4. Python Launcher for Windows New in version 3.3.

The Python launcher for Windows is a utility which aids in the location and execution of different Python versions. It allows scripts (or the command-line) to indicate a preference for a specific Python version, and will locate and execute that version.

From my console, I can see the "default" version via the py command...

C:\Users\me>py
Python 2.7.9 (default, Dec 10 2014, 12:28:03) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

C:\Users\me>py -3
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>

Here's the fundamental fix...

The key benefit of this is that a single launcher can support multiple Python versions at the same time depending on the contents of the first line.

The first line I had to add in my case to my script was

#! python3

Great commentary linked here for details and motivations behind the Launcher.