2to3 not working

[gladman]

BPO	24843
Nosy	@pfmoore, @tjguk, @zware, @eryksun, @zooba

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/zooba'
closed_at = <Date 2015-08-11.17:58:49.518>
created_at = <Date 2015-08-11.07:46:43.330>
labels = ['type-bug', 'invalid', 'OS-windows']
title = '2to3 not working'
updated_at = <Date 2015-08-11.18:09:19.200>
user = 'https://bugs.python.org/gladman'

bugs.python.org fields:

activity = <Date 2015-08-11.18:09:19.200>
actor = 'steve.dower'
assignee = 'steve.dower'
closed = True
closed_date = <Date 2015-08-11.17:58:49.518>
closer = 'eryksun'
components = ['Windows']
creation = <Date 2015-08-11.07:46:43.330>
creator = 'gladman'
dependencies = []
files = []
hgrepos = []
issue_num = 24843
keywords = []
message_count = 9.0
messages = ['248396', '248397', '248398', '248400', '248405', '248406', '248416', '248417', '248418']
nosy_count = 6.0
nosy_names = ['paul.moore', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'gladman']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue24843'
versions = []

[gladman]

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\puzzles.py
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.

[gladman]

I have now got it working using the command line:

C:\Program Files\Python35\Tools\scripts>"C:\Program Files\Python34\python" 2to3.py --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.

[eryksun]

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.

[gladman]

Thanks for the explanation. My apologies for this posting, which I will now close

[zooba]

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.

[gladman]

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 _msvccompiler.py).

best regards,

 Brian

[zooba]

Yes, I see. Thanks for clarifying, it seems all the installers are fine but Windows will generate associations that don't forward arguments.

[eryksun]

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.

[zooba]

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.)