On 7/21/2011 8:20 AM, Michael Foord wrote: > On 21/07/2011 15:43, Paul Moore wrote: >> On 21 July 2011 09:13, Glenn Linderman<v+python at g.nevcal.com> wrote: >>> Certainly when the launcher is invoked via an association, this would >>> be the case. However, when the launcher is invoked via the command >>> line, then the unqualified name is passed through. To be useful from >>> the command line, the launcher should walk the PATH to find the .py >>> file. >> It's equally as arguable (and would match my expectations much more >> closely) that "py a_file.py" should do whatever "python a_file.py" >> would do. So path search in that context would only be reasonable if >> it were a Python feature rather than a feature of the launcher. >> >> This is what the launcher currently does (so I guess it's not >> surprising that I'm happy with the current behaviour). >> >> I can see the benefits of path search, but I'd want it to be a Python >> feature (and hence inherited "for free" by the launcher) and not a >> launcher-only one. > > What he said ^^. (+1) > > py launcher and python binaries behaving differently in this regard > would be a recipe for confusion and hard to debug problems. I see the point. Although the incremental benefit is higher to Windows users, and although we are creating a Windows-only piece of code that could be the vehicle for adding the functionality, it would be beneficial for all platforms, and a common implementation would serve that need better. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20110721/7490ea4b/attachment.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4