Using batch files is a poor idea, IMO, because you have to explicitly call a batch file from another, or the remainder of the caller will not execute. Installing to System32 s also questionable, but if it's just the launchers, it might be okay. From an installer's perspective, it would really help if those files kept consistent component GUIDs and had a Windows version block so it could upgrade consistently if it changes in the future I think Glenn Linderman hit the use cases on the head; I'm unclear why he was against the overhead of a helper executable. The things I would really want solutions for are these: * double click on a script, and have it launch the right python (2 or 3, w or not) * Probably scan for the final python[.\d]+ string and assume it's relevant. * be able to easily invoke python to interpret a script from the command prompt I'd be comfortable with setting associations to a set of thin executable wrappers which examined the #! line to extract a python version. It could fall back to the "default" version of python, which could be defined as the highest installed on the machine, or could be customizable by the machine's administrator. If this wrapper script passes on all command line parameters, it could also be a reasonable way to invoke python from the command line. Is there a good way for the wrapper to know what versions of python are available on Windows? Moving forward we could have a pythonx.y installer set a value in a known registry key, and document how to register an older python with this key. The default value of the key could be the mechanism for setting a default python version. I'm willing to clarify this and/or look into providing patches if it would help; the only potentially sticky point is the contribution agreement, but I wouldn't expect trouble with my employer. Michael