This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author chrullrich
Recipients chrullrich
Date 2015-11-16.18:37:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1447699025.13.0.574177201603.issue25636@psf.upfronthosting.co.za>
In-reply-to
Content
As described in PEP 397, the launcher can autoselect the "best" Python version available on a system, or a full version number (major.minor) can be specified. In the latter case, optionally a "-32" suffix can be given to select a 32-bit version, which is useful on 64-bit systems where a 64-bit Python is also present. By default it will select the highest (native) version.

I have an application that runs unmodified on Python 3.[345], but only with the 32-bit version because it loads a DLL (this is on Windows, but I think the basic issue applies to other systems as well) that has no 64-bit version available. I would like to run it on any system that has *any* suitable Python installed.

However, with the version selection syntax supported by the launcher, I can only demand a 32-bit version if I also specify the Python minor version I want, and I do not necessarily know that in advance.

What I would like the launcher to support is a version specification that allows using the "-32" suffix in all possible combinations with version numbers:

py -3.5-32 (same as today, 32-bit Python 3.5)
py -3-32   (highest 32-bit Python 3)
py -32     (highest 32-bit Python available)

The last form above, with no major version given, would look for the highest minor version in the default major version. The syntax might have to be different for compatibility reasons, although both incomplete specifications would result in an error message in all released versions.

I have been looking for a reason this limited syntax was chosen, but there has not to my knowledge been any discussion of this change on python-dev, and the May 2011 revision to PEP 397 ("based on python-dev feedback") in which it was introduced over the original, more flexible syntax also gives no further hint about its reasoning.

Solving this in application code could be done, of course, but both apparent solutions are incredibly ugly:

- Reimplementing the version autoselection by listing the available 32-bit versions.
- "Shooting blind", invoking every possible version from the top down until one works.
  "3.5-32? Nope. 3.4-32? Nope. 3.3-32? Yes!" This approach has the added downside that
  the launcher may not be in the $PATH at all. That is improbable, but possible.

I would much rather leave the work to the launcher, where the required knowledge is obviously available.

Thanks for hearing me out :-)
History
Date User Action Args
2015-11-16 18:37:05chrullrichsetrecipients: + chrullrich
2015-11-16 18:37:05chrullrichsetmessageid: <1447699025.13.0.574177201603.issue25636@psf.upfronthosting.co.za>
2015-11-16 18:37:05chrullrichlinkissue25636 messages
2015-11-16 18:37:03chrullrichcreate