I am running Python 2.6.4 on Windows Vista and when I try to get any command line arguments via sys.argv, it only contains sys.argv[0], but nothing else. Even if I supply several parameters. The only third-parts modules I am using are Pygame, but even before Pygame imports, there is nothing in sys.argv. I've tried creating a shortcut with the args in it, but it still doesn't work.
Note that I also have a couple other Python versions installed (2.5, 2.7a, and 3.1) maybe somehow they are conflicting?

How do you supply parameters to your script?
Did you add the association for ".py" files yourself?

From a command prompt, type:
assoc .py
this displays a string like ".py=Python.File". Now type
ftype Python.File
(actually replace Python.File with the output from the first command)
This should display something like
Python.File="C:\Python26\python.exe" "%1" %*
If %* is missing, then arguments are not passed to the python interpreter.

Actually, I was playing around with it and I found that using the "python" command before it does work.
Now, when I type what you said to do, it shows that there is no association, even though i can run a program without the python command.
This is quite strange...

Sorry for a double-comment, but I thought of posting this after I already submitted the last one and I found no edit button.

Here's some output:

"Microsoft Windows [Version 6.0.6001]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.
C:\Users\JT>assoc .py
File association not found for extension .py
C:\Users\JT>assoc py
File association not found for extension py
C:\Users\JT\Desktop\Programming Projects>pythonversion.py
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
C:\Users\JT\Desktop\Programming Projects>ftype Python.File
File type 'Python.File' not found or no open command associated with it.
C:\Users\JT\Desktop\Programming Projects>assoc py
File association not found for extension py
C:\Users\JT\Desktop\Programming Projects>assoc .py
File association not found for extension .py
C:\Users\JT\Desktop\Programming Projects>assoc .pyw
File association not found for extension .pyw
C:\Users\JT\Desktop\Programming Projects>assoc pyw
File association not found for extension pyw
C:\Users\JT\Desktop\Programming Projects>assoc pyc
File association not found for extension pyc
C:\Users\JT\Desktop\Programming Projects>assoc .pyc
File association not found for extension .pyc
C:\Users\JT\Desktop\Programming Projects>assoc .pyo
File association not found for extension .pyo
C:\Users\JT\Desktop\Programming Projects>assoc pyo
File association not found for extension pyo"

(Sorry it's so long, I cut out the blank lines as it is)

I'm getting something like this on Windows 7:

C:\>assoc .py
.py=Python.File

C:\>ftype Python.File
Python.File="C:\Python31\py31.exe" "%1" %*

C:\>args.py 1 2 3
Python version: sys.version_info(major=3, minor=1, micro=1, releaselevel='final', serial=0)
Command-line args: 1
['C:\\args.py']

C:\>\python31\py31 args.py 1 2
Python version: sys.version_info(major=3, minor=1, micro=1, releaselevel='final', serial=0)
Command-line args: 3
['args.py', '1', '2']

I've read on a random forum somewhere that % need to be doubled on Windows 7.
Tom, can you try changing the association by typing
FTYPE Python.File="C:\Python31\py31.exe" "%%1" %%*

No joy :(

I tried putting double-quotes around %%*, that didn't work either. Tried single-quotes too, just in case it works like a Bourne-type shell.

BTW I forgot to set 3.1 on my earlier message.

That business about having to double the % rings a faint bell from the old MS-DOS days, though. Can't remember. Something about, it will interpret it once, so you have to make sure it comes out the way you want after it does that. (Which is old hat to anyone who does much programming in a Unix shell, but it was new to me back then.) I remember it was rather difficult to get it right.

Closed bpo-8984 as a duplicate of this; merging nosy lists.

Tom, did you ever find a solution to this problem?

Here's a link to a similar discussion about Perl on Windows:

http://community.activestate.com/forum-topic/problem-passing-arguments

From various other sites, and from experiments (thanks Eric Smith) it looks like the associations reported by 'assoc' and 'ftype' aren't necessarily the associations that are actually being used.

Sworddragon: can you get any useful information out of the Windows registry (e.g., using regedit, searching for Python.File, and looking under shell\open\command), or by setting file associations through the Control Panel?

I don't know enough about Python on Windows to know whether there's any hope that this is a problem that can be solved at the Python end, but I'd guess not.

I agree with Mark: there's probably nothing Python can do about this. It's almost certainly an error with how Python is being invoked.

That being said, it would be interesting to see what the registry key HKEY_CLASSES_ROOT\Python.File\shell\open\command contains.

This registry key contains "E:\Python31\python.exe" "%1" %*. I have too 2 python versions installed and manually associated the .py files to Python 3.

I have set now the key to "E:\Python31\python.exe" "%%1" %%* and it works. So Windows XP need double % too. The installer of the next version should consider this.

I made a mistake in the last post. After I have set the value, Python 2 was active and I forgot to set it to Python 3 back. This solution doesn't work. Well, I can't edit or delete the post.

Now I found the real solution (and don't forgot to set it to Python 3 back). I have searched in the registry for python.exe to look how Python 2 is doing this. I sawed a key that looks dissimilar to the others before. It is the key HKEY_USERS\S-1-5-21-1078081533-682003330-1801674531-1003\Software\Classes\Applications\python.exe\shell\open\command which have the Standard value of "E:\Python31\python.exe" "%1". I set it to "E:\Python31\python.exe" "%1" %* and it worked.

So the real question is is: how does that key get that invalid value? I can't reproduce the problem.

I believe that key you mention is an alias for HKEY_CURRENT_USER\Software\Classes\Applications\python.exe\shell\open\command, which doesn't exist on my XP machine.

I have now uninstalled Python 2 and 3 and installed them new. First Python 2 with only register extension and compile files to bytecode. After this I have made the same with Python 3. In the "Open with" menu was now "python" registered which was Python 3 (sys.version[0] from a testscript telled it me). Until this point the arguments were accepted. After this I have added the python.exe from Python 2 to the "Open with" menu. This was the point where the key got invalid. Now Python 3 is working correctly but not Python 2. Well, I can manually use now the workarround to fix it but maybe the problem can be solved with this information.

The problem went away by itself after a while. I suspect a Windows update.

I found this page while encountering the same problem (only one argument, the scriptname, being passed in from the command line), and wanted to post the following workaround. I'm running Vista and using Python 2.6.
In summary I had to have 'python' at the beginning of the command line.
I found:
this did not work: c:\>django-admin startproject mysite
this DID work: c:\>python django-admin startproject mysite

Before finding this fix:
I had tried the 'ftype Python.File' and 'assoc .py' commands mentioned in other posts above and gotten the equivalent of 'not found'.
I actually found the correct info in the registry under HKEY_CURRENT_USER, but 'ftype' and 'assoc' don't appear to read from there.
I modified the registry under HKEY_LOCAL_MACHINE, and then I was getting the responses that were claimed to be needed in msg99369 above, but this did NOT fix the problem.
It was after the above that I found the solution - use 'python' at the beginning of the command line and all args are passed in.
(I did not go back and remove the registry edits that I made to prove conclusively that they are not part of the solution, but I doubt that they are.)

Encountered the same issue with 3.1.2 and 3.1.3 64bit on Win7 64bit. I was able to fix it in registry but did so many changes at once that I'm not able to reproduce (was really annoyed after trying to fix it for half a day...). Anyway, sending my observations:

• the root cause seems to be creation of "python.exe" and "pythonw.exe" entries under HKEY_CLASSES_ROOT. Their open command did not have %*. They were not created under HKEY_LOCAL_MACHINE. They were probably created automatically by the system when manually associating py and pyw files (see below).
• .py and .pyw files were originally associated with py_auto_file and pyw_auto_file in HKCR. The associations were probably created by the system, when I manually change association of the .py and .pyw files from jython to python through control panel. The py_auto_file and pyw_auto_files seemed to call those python.exe and pythonw.exe entries in the HKLC.
• The assoc and ftype commands changed association in HKLM but it is not propagated automatically into HKCR, not even after restart. After manually deleting .py and .pyw entries from HKCR, they were replaced by correct entries from HKLM.
• BUT!! the system still called open commands under python.exe and pythonw.exe entries in HKCR! (even if .py was associated with Python.File in HKCR and proper Python.File existed even in HKCR!) Only after deleting them, it works as should. But I deleted a lot of other python related entries as well, so this is only assumption.

If anyone else can confirm that deleting of python.exe and pythonw.exe from HKCR itself corrects the issue, I think the installation program can check if these entries exists and offer to delete them.

Just for complete picture, it works now even with .py and .pyw in PATHEXT, so calling the scripts without extension.

I'm sorry, I changed version to 3.3 by mistake. Did not want to do it.

I had the same problem with another version of python on Windows 7.

We are using python 2.4.2 for production and it is installed in D:\Tools\Python. For experimentation purpose, I installed Python 2.7 in the usual location. It broke a few things and I uninstalled both python, and reinstalled only 2.4.2.

After that, using python 2.4.2, I got the problem described by this issue. None of my colleagues (who did not install Python 2.7) had the issue.

The registry entry HKEY_CLASSES_ROOT\py_auto_file\shell\open\command was reading: D:\Tools\Python\python.exe "%1"

It was missing %*. I added it and my issue went away.

I finally found a solution from a page on StackOverflow.
I had to add the two characters %*
to the end of the Data value for the Windows registry key:
HKEY_CLASSES_ROOT\Applications\python.exe\shell\open\command
So the Data value is now:
"C:\Python26\python.exe" "%1" %*
just as it appears above including the two sets of double quotes.

I had modified or added six other keys but only the one above solved the problem.
I am running Python 2.6 under MS Windows Vista Home Premium 32 bit.
For completeness I tested potential fixes as follows:
I had a program show_args.py which had the two lines:
import sys
print 'argv length is ', len(sys.argv)
In order for show_args.py to receive args from the command line invocation (before I did the registry fix) I had to explicitly call the python interpreter, so ...

Before the fix:
C:\...>python show_args.py aaa bbb ccc
argv length is 4
C:\...>show_args.py aaa bbb ccc
argv length is 1

After the fix:
C:\...>show_args.py aaa bbb ccc
argv length is 4

In hindsight I should have searched the registry for python paths that didn't have the ending %*.

Very briefly, for those unfamiliar with Windows' RegEdit:
Click the Start button and enter regedit in the Search box and the Regedit.exe name will appear in the list above - click it.
Repeatedly do Edit/Find python.exe
until you find a python path of the form: ...\python.exe" "%1"
instead of the form ...\python.exe" "%1" %*
In the right pane of Regedit, under Name click the word (Default), it will turn blue, then select Edit/Modify...
Simply add a space and the two chars %* to the end of the entry in the Value data box, then click OK.
Changes take effect immediately; you don't have to reboot or re-open your prompt window, but if you are using IDLE or another IDE you probably have to close and restart it.

I have v2.7, v3.2, and v3.3 installed on a Win7 64-bit machine and the exact same setup on a Win7 32-bit machine.

The 32-bit works OK. The 64-bit machine had this argv problem, too! (I tried installing either Win32/Win64 version, no difference!)

Adding %* fixed the argv problem, but I noticed there was one more. The wrong version was called.

To sum it up, I had to change only the key
HKEY_CLASSES_ROOT/py_auto_file/shell/open/command

from:

c:\Python32\Python32.exe "%1" %*

to:

c:\Python33\Python33.exe "%1" %*

or to:

c:\windows\py.exe "%1" %*

(for auto-detection, both worked)

I ran into this issue by doing the following steps, though I did not try to reproduce:

1 - install Python 3.4
2 - have windows Always Open .py files with Python
3 - install Python 2.7

Then I encountered issues where all .py scripts were opened with Python 2.7. After some unsuccessful attempts I decided to uninstall Python 2.7

4 - remove Python 2.7

At this point, I had to update the file associations because Windows could not find Python 2.7 anymore

5 - update file associations

The issue is obviously that in at least a few places in the registry, the ..\shell\open\command has a value of ..\python.exe "%1"

In my case it was under all roots:

HKEY_CLASSES_ROOT\py_auto_file
HKEY_LOCAL_MACHINE
HKEY_USERS

I corrected only the one under HKEY_USERS by adding %* and it resolved the issue.

@alecz are you aware of the Python launcher, see https://www.python.org/dev/peps/pep-0397/ and https://docs.python.org/3/using/windows.html#python-launcher-for-windows ? The easiest way to sort out 3.4 would have been to download the msi file and use the repair option.

Having said that I've no idea whether or not this issue can be sorted out, or is already sorted in 3.5. @Steve, Zach or Tim, over to you :)

I am closing this because there is no identifiable issue with the current installers. Initial issues were reported fixed. The most recent issue reported by Alecz was that installing 2.7 after 3.4 caused python files to be opened by 2.7. This is what should happen when 2.7 is installed as the default python (there is an option to select this or not). Questions about using python.org installers or python should be directed elsewhere, such as python-list.