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 mariofutire
Recipients eric.snow, mariofutire, ncoghlan, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
Date 2018-10-08.20:19:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <911419f5-6f0e-7f76-1cf8-00ed3640d5c4@gmail.com>
In-reply-to <1539017666.48.0.545547206417.issue34725@psf.upfronthosting.co.za>
Content
On 08/10/2018 17:54, Steve Dower wrote:
> 
> Steve Dower <steve.dower@python.org> added the comment:
> 
>> Py_SetProgramName() should be a relative or absolute path that can be used to set sys.executable and other values appropriately.
> 
> Key point here is *can be*, but it doesn't have to be. Given it has fallbacks all the way to "python"/"python3", we can't realistically use it as sys.executable just because it has a value.
> 
> And right now, it's used to locate the current executable (which is unnecessary on Windows), which is then assumed to be correct for sys.executable. Most embedding cases require *this* assumption to be overridden, not the previous assumption.

I still would like my use case to be acknowledged.

site.py uses the value of sys.executable to set up a virtual environment, which is a very valuable 
thing even in an embedded cases.

This constraint is strong enough to force it to point to python.exe or python3 as it would normally 
do in a scripted (non embedded case).

I still believe the 2 concepts should be decoupled to avoid them clashing and having supporters of 
one disagreeing with supporters of the other.

Andrea
History
Date User Action Args
2018-10-08 20:19:22mariofutiresetrecipients: + mariofutire, paul.moore, ncoghlan, vstinner, tim.golden, eric.snow, zach.ware, steve.dower
2018-10-08 20:19:22mariofutirelinkissue34725 messages
2018-10-08 20:19:22mariofutirecreate