[Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Glenn Linderman]

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110308/be330644/attachment.html>