Title: 2to3 not working
Type: behavior Stage:
Components: Windows Versions:
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: steve.dower Nosy List: eryksun, gladman, paul.moore, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2015-08-11 07:46 by gladman, last changed 2015-08-11 18:09 by steve.dower. This issue is now closed.

Messages (9)
msg248396 - (view) Author: (gladman) Date: 2015-08-11 07:46
when I try to use the 2to3 script on the command line on Windows x64, I get the response:

  C:\Program Files\Python34\Tools\scripts>2to3 C:\Users\brian\Downloads\
  At least one file or directory argument required.
  Use --help to show usage.

When I ask for help I get:

  C:\Program Files\Python34\Tools\scripts>2to3 --help
  At least one file or directory argument required.
  Use --help to show usage.

In fact this is always the response I obtain irrespective of what I enter after '2to3' on the command line.  Python 3.5rc1 also behaves in the same way.
msg248397 - (view) Author: (gladman) Date: 2015-08-11 08:01
I have now got it working using the command line:

C:\Program Files\Python35\Tools\scripts>"C:\Program Files\Python34\python" --help

I am not sure why the default Windows invocation of Python doesn't work with 2to3 as this works fine with other python scripts that I have tried.
msg248398 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2015-08-11 10:18
Your .py file association isn't configured to pass command-line arguments. Revert to using the "Python.File" type that was created by Python's installer. The associated command should be something like 

    "C:\Windows\py.exe" "%1" %*

depending on where py.exe is located.
msg248400 - (view) Author: (gladman) Date: 2015-08-11 10:49
Thanks for the explanation. My apologies for this posting, which I will now close
msg248405 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-08-11 13:04
If this occurs in 3.5 then it needs to be fixed (though I thought I'd already fixed it once...).

I'll take a look.
msg248406 - (view) Author: (gladman) Date: 2015-08-11 13:59
Hi Steve,

The behaviour I reported was the same on Python 3.4 and 3.5rc1.  But eryksun was correct in suggesting that this was a problem in the way my file association for Python was set up. My py_auto_file association was set to: 

"C:\Program Files\Python34\python.exe" "%1"

adding %* on the end fixed the problem.
(by the way, thank you for your work on

   best regards,

msg248416 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-08-11 17:48
Yes, I see. Thanks for clarifying, it seems all the installers are fine but Windows will generate associations that don't forward arguments.
msg248417 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2015-08-11 17:56
> My py_auto_file association

Oh, it's that auto filetype again. Steve, when you say you fixed this for 3.5, does that means there's a simple command or API to revert this automatic ProgId back to the Python.File type? This problem shows up repeatedly on Stack Overflow, so it would be nice to have a solution that works consistently from Windows 7 to 10. 

cmd.exe's built-in assoc and ftype commands only modify the local machine association and filetype. A per-user install doesn't use those, and sometimes Explorer instead uses a per-executable command defined in Software\Classes\Applications. Also, just modifying the command doesn't actually select what ShellExecuteEx will choose to run. I used to directly modify Explorer's FileExts\...\UserChoice for a given file extension, but that's actively discouraged by a deny ACL nowadays. Fine, but I've run into cases where Explorer's dialog doesn't let me choose a an existing ProgId.
msg248418 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2015-08-11 18:09
I'm afraid there's no easy way to revert it. I may get to invest the time for 3.6's launcher[1] to make it available in Default Programs, but I've always struggled to get that to work properly.

Explorer should always use the per-user command if it's there, and it's basically the responsibility of users to not change it if they don't want it to change.

[1] The launcher owns the shortcut, not the core Python installation - the separation is only important to users in that if you don't include the launcher you don't get the association, and if you install the launcher for all users then the shortcut is for all users.

(Also cleared the Versions field, since Python 3.4 creates the correct association too. Preventing user customization on a user's machine is not something we're going to get into, but that's the only way to "solve" this problem.)
Date User Action Args
2015-08-11 18:09:19steve.dowersetmessages: + msg248418
versions: - Python 3.4
2015-08-11 17:59:27eryksunsetversions: + Python 3.4, - Python 3.5, Python 3.6
2015-08-11 17:58:49eryksunsetstatus: open -> closed
resolution: not a bug
2015-08-11 17:56:52eryksunsetstatus: closed -> open
versions: + Python 3.5, Python 3.6
messages: + msg248417

assignee: steve.dower
resolution: not a bug -> (no value)
2015-08-11 17:48:47steve.dowersetstatus: open -> closed
versions: - Python 3.5, Python 3.6
messages: + msg248416

assignee: steve.dower -> (no value)
resolution: not a bug
2015-08-11 13:59:30gladmansetmessages: + msg248406
2015-08-11 13:04:53steve.dowersetstatus: closed -> open
assignee: steve.dower
messages: + msg248405

versions: + Python 3.5, Python 3.6, - Python 3.4
2015-08-11 10:49:01gladmansetstatus: open -> closed

messages: + msg248400
2015-08-11 10:18:44eryksunsetnosy: + paul.moore, tim.golden, eryksun, zach.ware, steve.dower
messages: + msg248398
components: + Windows, - 2to3 (2.x to 3.x conversion tool)
2015-08-11 08:01:04gladmansetmessages: + msg248397
2015-08-11 07:46:43gladmancreate