[Python-Dev] PEP 379 Python launcher for Windows - behaviour for #!/usr/bin/env python line is wrong

[Paul Moore]

On 4 May 2013 15:20, Vinay Sajip <vinay_sajip at yahoo.co.uk> wrote:

> Paul Moore <p.f.moore <at> gmail.com> writes:
>
> > This will mean that scripts written with #!/usr/bin/env python will
> > behave the same on Unix and Windows in the presence of activated
> > virtualenvs.
>
> Overall I think it's the right result. There's one other compatibility
> clarification: at the moment, as allowed by the PEP, you can have launcher
> flags in a line that starts with #!/usr/bin/env python, for example
>
> #!/usr/bin/env python3.2-32 -u
>
> In such a case the launcher would use the 3.2-32 suffix to indicate that
> 32-bit Python 3.2 is wanted, and pass the -u to the launched executable. I
> assume that this behaviour should continue, and the Posix-compatible
> behaviour
> being proposed should only apply for lines that contain
>
> "#!/usr/bin/env python"
>
> followed by whitespace.
>

That sounds reasonable - I've never used the ability to add flags, but I
agree that as there's no equivalent in POSIX, there's no reason to change
the current behaviour in that case.


> Also, since we're making a backwards incompatible change, do people feel
> that
> it needs to be switched on only in the presence of e.g. an environment
> variable
> such as PYLAUNCH_SEARCHPATH, or should we just change the default behaviour
> now and risk breaking user scripts which may rely on the current behaviour?
>

Personally, I'd say make it unconditional - the current behaviour is
unlikely to ever be what people actually *want*.

But if the consensus is to make it conditional, could we have a flag in
py.ini rather than an environment variable? That would be more consistent
with normal Windows practice.

Paul.

PS Vinay - from this post, I assume you're already looking at this code? I
was considering trying to put together a patch, but I don't want to
duplicate effort if you're working on it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130504/1192c78f/attachment.html>