On 3/8/2011 8:02 PM, Toshio Kuratomi wrote:
On Tue, Mar 08, 2011 at 06:43:19PM -0800, Glenn Linderman wrote:
On 3/8/2011 12:02 PM, Terry Reedy wrote:
On 3/7/2011 9:31 PM, Reliable Domains wrote:
The launcher need not be called "python.exe", and maybe it would be
better called #@launcher.exe (or similar, depending on its exact
function details).
I do not know that the '#@' part is about, but pygo would be short and
expressive.
If my proposal to make a line starting with #@ to be used instead of the Unix
#! (#@ could be on the first or second line, to allow cross-platform scripts to
use both, and Windows only scripts to not have #!
You'd need to allow for it to be on the third line as well. pep-0263
has already taken the second line if it's in a script that has a Unix
shebang.
Thanks for your feedback Toshio...
Indeed! I've been using Python 3 and UTF-8 encoding only long enough, I
forgot about pep-0263, although I'd been aware of it before... Now I
only port back to Python 2 for stuff I have to run on my web host, which
runs Python 2.6, and those are all ASCII files by design.
), then #@launcher.exe (and #
@launcherw.exe I suppose) would reflect the functionality of the launcher,
which need not be tightly tied to Python, if it uses a separate line. But the
launcher should probably not be the thing invoked from the command line, only
implicitly when running scripts by naming them as the first thing on the
command line.
I'm of the opinion that attempting to parse a Unix #! line, and intuit what
would be the equivalent on Windows is unnecessarily complex and error prone,
and assumes that the variant systems are configured using the same guidelines
(which the Python community may espouse, but may not be followed by all
distributions, sysadmins, or users).
I do not have a Windows system so I don't have a horse in this race but if
the argument is to avoid complexity, be careful that your proposed solution
isn't more complex than what you're avoiding. ie::
Yep, even after I wrote the below, I thought about not sending that
part, for exactly that reason.
But after slightly investigating the other Python implementations, I
realized even more strongly that interpreting the Unix #! line is very
limiting:
1) it requires the same version to exist on both Unix and Windows, which
may often, but not always, be true.
2) it either hard-codes an alternative path name in the launcher, or
hard-codes an algorithm to do lookups in the registry to find the
alternative path names. Neither of these are very friendly to
alternative Python implementations.
3) people concerned with keeping scripts and modules compatible with
alternative implementations might have more than one implementation on
their system.
So the complexity I'm avoiding is the "hard-coding" sort of complexity.
The complexity I propose adds flexibility that the hard-coding would be
hard-pressed to achieve.
Now that I've had this idea, one might want to create other "2nd character"
codes after the Unix #! line... one could have
#! Unix command processor
#@ Windows command processor
#$ OS/2 command processor
#% Alternate Windows command processor.
One could even port it to Unix:
#!/usr/bin/#@launcher
#@c:\python2.6\python.exe
#^/usr/bin/python2.5
#&/usr/bin/mono/IronPython2.6 for .NET 4.0/ipy.exe
# I made up the line above, having no knowledge of Mono, but I think you get
the idea
Choice of command line would be an environment variable, I suppose, that the
launcher would look at, or if none, then a system-specific default. It would
have to search forward in the file until it finds the appropriate prefix or a
line not starting with #, or starting with "# " or "##", at which point it
would give up.
For PEP-0263 compliance, modify the terminator to be a line not starting
with #, or a line starting with "##". This may cause reduced
performance for scripts starting with large block comments without
having the searched-for execution code... but only in the case where the
searched-for execution code is not present.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
