Author eryksun
Recipients docs@python, eryksun, gaborjbernat, keller00, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
Date 2020-10-18.21:17:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1603055850.02.0.750047820395.issue42041@roundup.psfhosted.org>
In-reply-to
Content
> You can build a cross-platform wrapper on top of native behaviour 
> (witness `shutil.which`) but you can't do the opposite.

Nothing would prevent adding a parameter to use the platform semantics, if that had been in the design from the outset. But it's not something we should change at this stage. It's too fundamental.

> I'm not convinced that using `shutil.which` is the right 
> answer for anything other than "python".

Actually, I think shutil.which() is the right answer generally (within the filesystem scope) except for "python", for which sys.executable is usually what people want, i.e. the current interpreter. A PATH search via shutil.which('python') doesn't necessarily find the current interpreter, if anything at all. So I'm not arguing against advice to use sys.executable, but rather that recommmending shutil.which() should be done in a more generic way that's separate from the "python" problem. 

For platform semantics, I'd prefer a link to the CreateProcessW docs, with advice to read about the lpApplicationName parameter with respect to `executable` and lpCommandLine with respect to `args` and the platform search semantics. The CreateProcessW docs are rather long and off-putting, so I think it helps to narrow it down for people, and explicitly map between Popen() and CreateProcessW parameters.

Over the years, I've come across many forum questions in which novice users waste days on problems with respect to Windows quirks that can be resolved in a minute or so by someone with knowledge and experience. They get lots of advice with good intentions from programmers who only have POSIX experience (the Python ecosystem online is still heavily dominated by POSIX, despite the number of Windows users), and it's mostly wrong advice and a waste of their time (not even a learning experience). Documenting platform inconsistencies helps experienced programmers to use the docs in order to help novice programmers. It's not necessarily about helping novices directly. Often just a nudge in the right direction is enough.
History
Date User Action Args
2020-10-18 21:17:30eryksunsetrecipients: + eryksun, paul.moore, vinay.sajip, tim.golden, docs@python, zach.ware, steve.dower, gaborjbernat, keller00
2020-10-18 21:17:30eryksunsetmessageid: <1603055850.02.0.750047820395.issue42041@roundup.psfhosted.org>
2020-10-18 21:17:30eryksunlinkissue42041 messages
2020-10-18 21:17:29eryksuncreate