Message327370
| 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 |
|