On 07/03/2011 22:48, Mark Hammond wrote:
> On 8/03/2011 7:33 AM, Michael Foord wrote:
>> A python launcher as you describe is a *great* idea.
>>
>> A few concerns:
>>
>> * we're missing an opportunity to do something easy (Martin is happy to
>> modify the installer and says it is easy) for something that may or may
>> not happen
>
> Don't let my -0 stop anyone :)
Will you be at PyCon this year?
>
>> * will you call it python.exe? will it be installed by the python
>> installer?
>>
>> - I doubt calling it python.exe will fly, but I'm not sure. If so what
>> will you call what is currently 'python.exe'? - if not then "python
>> foo.py" on the command line will *still* not work...
>
> Calling it python.exe would make the most sense for people who don't
> look behind the curtain, but I agree it could potentially be confusing
> for people. Further, we would need to ensure we didn't create an
> infinite loop where the launcher python.exe found a python.exe it
> thought was an appropriate sub-process, but where it turns out it is
> actually another launcher.
>
Sounds like fun. :-)
> Having it installed by the Python installer also makes sense to me but
> I'd be very interested in Martin's take on this (and also on
> everything else we are discussing here).
>
Ditto.
>> * we're (yet again) making instructions for running stuff on Windows
>> *different* to other platforms (and making tutorials written for other
>> pythons "not work" in certain ways)
>
> Actually, I'd argue we are making them more similar as we would be
> honoring a shebang line and allowing the exact same mechanism be used
> to denote the major version of Python needed.
>
Well, except (as pointed out a few minutes ago) that *isn't* what unix
does ("python foo.py" does not honour the shebang). It gets us to
something that works reliably though so I still like the idea.
>> * as I work with multiple platforms it would be really nice if the same
>> invocations worked across all of them - whilst I say again that I really
>> like the idea of the launcher it doesn't conflict with the other
>> suggestions (creating multiple binaries) and as you (Mark) say it
>> wouldn't hurt...
>>
>> So why not do both? We could create the extra binaries to bring Python
>> on Windows inline with the unix conventions for command line
>> invocations, and the new launcher can follow on as a nice addition.
>>
>> Note that the discussions about the Python installer adding to the PATH
>> won't be *ended* by the creation of the installer. A typical install on
>> a Unix-like system adds various other utilities to the path that merely
>> adding the top-level of your Python install on Windows still doesn't
>> add. In particular distutils installed scripts go into a subdirectory of
>> your Python install.
>
> The distutils scripts are a good point. To be honest, apart from the
> "file association" issue, I can't see much advantage in doing both -
> if all Python directories end up on your path such that "python3
> foo.py" magically works, then the launcher script is adding complexity
> without bringing much to the table. Further, I'm somewhat skeptical
> that the file associations are used by that many people in the real
> world - currently when you double-click on a script you get a temp
> console created, and should a traceback be raised, you get to see it
> for about 2ms before the console is destroyed. Some people may be
> .pyw to avoid that, but then their script has to go to extraordinary
> lengths to display such errors in a UI of some kind. I suspect most
> people just find it more convenient to launch such scripts from a
> console. Maybe a quick poll on python-list would be reasonable...
The launcher program could thrive without *having* to be part of a
standard Python install. Offering it separately makes sense even if it
*is* included. If we do both then users can vote with their feet.
Personally I suspect that many people, particularly new programmers,
will appreciate the launcher but more advanced developers will want more
precise control (and similarity to unix for command line invocations).
I agree with you about file associations. They are useful for .pyw
programs (like IDLE), but not for scripts.
All the best,
Michael
>
> Cheers,
>
> Mark
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.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