[Python-ideas] Re: About python3 on windows

[Paul Moore]

On Thu, 26 Mar 2020 at 22:11, Cameron Simpson  wrote:
>
> It seems to me that there is a deliberate choice to _not_ install the
> "python3" executable name when installing Python 3 on Windows, and to my
> eye that is/was a _bad_ choice. I would like to see a good explaination
> as to why that choice was made.

I don't think that's quite right. Originally, the choice was to
install "python", and that was it. That was true on Unix as well. When
Python 3 came along, Unix needed to have both python (=python 2) and
python3. But the reasons for that (distros using python 2 for system
scripts) didn't apply on Windows, so there was no need for a change
there. Maybe that was a mistake, and compatibility with Unix should
have been seen as more important than maintaining the existing model
on Windows. But IMO, it wasn't so much a deliberate choice to not
provide python3, more of a lack of any decision to do so.

The fact that the situation hasn't been reviewed, and hasn't been
changed, is likely mostly just inertia. That, plus the fact that there
simply haven't been that many complaints. Sure, this thread has
generated a lot of discussion, but it's just one thread, triggered by
one poster with a very specific situation. I'm not saying that we
should ignore the issue - I doubt that shipping a python3.exe is a
huge effort in practice - but I'm not aware that this is as widespread
an issue as all that.

So honestly, I don't think there's any useful information or
explanation to be had from the history. Unless there's been a previous
request to add python3.exe that got blocked, I think we just sort of
got here by *not* making any specific decisions.

> Choosing Python 3 specificly is an important choice for many scripts
> because 2->3 was a breaking change.

Well, certainly for some scripts. But not

* If you don't share your script
* If you only share scripts between people using the same Python version
* If you only use a single OS (you can use OS-specific approaches to
choose a Python version)
* If you bundle your script into a wheel or application

It's really only scripts that need to be shared as simple scripts
between machines with a variety of operating systems and a variety of
Python versions that have a really difficult problem to address here.
I don't know what proportion of scripts that would be. However, I also
don't see that how many scripts are affected is any reason *not* to
make things easier for them, if doing so is straightforward.

Maybe someone should just raise a PR for 3.9, to include versioned
exes in the Windows installers (and the various other Windows
distributions)? If there *are* any good reasons to object, they'd come
up in PR review, I imagine.

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KAV3FEL2D4G2A34IMG3IR5WFVFHF3EZ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Cameron Simpson]

On 23Mar2020 17:59, Frédéric De Jaeger  wrote:
There is a recurring problem in my company where we use python in 
various places (python3).

We do cross platform development windows/linux and our python scripts need to 
run everywhere.
Some scripts are launched manually in a terminal.
Others are launched via windows' gui interface.
Others are launched through our build process (cmake based, but also manual 
Makefile)
And others are launched via bash scripts.
And possible several other scenario I've forgot.

On windows, most users use Cygwin to do their terminal based business (`git`, 
`cmake`, ...).

The issue is:  There is no reliable way to launch a python script.

The command:

python myscript.py

launches python3 on windows and python2 on 99% of the unix market.

The command

  python3 myscript.py

does not run on windows with the latest python distribution I've played with 
(sorry if it has been fixed recently, this whole mail becomes pointless).

[...]
If the standard python distro would just provide a simple `python3` 
binary/alias, then all the stars would align perfectly.

the basic shebang

#! /usr/bin/env python3

would work everywhere by default, without requiring any tweaking (install a 
python3 alias on windows, or ask linux users to change the default `python` 
symlink)

I'm sure, I'm far from being the first user complaining about that.  
Sorry if the request has been been made numerous time before.


I'm sticking my oar in here because this whole thread seems to sidestep 
Frédéric's question: WHY isn't there a python3.exe installed with a 
version 3 Windows python install?


With that, the "#!/usr/bin/env python3" and command line "python3" 
invocations would Just Work.


There might be fiddling around locating the specific python3 (see Eryk's 
long posts about how the launcher and various environments do their 
searching), but at least the user would always get a version 3 Python, 
and if there's just one Python 3 on the box, they always get the 
_correct_ Python 3.


The point isn't "what Python does 'python' get you?", it is "why can't 
we make 'python3' find a Python 3 universally, including from a 
shebang?"


It seems to me that there is a deliberate choice to _not_ install the 
"python3" executable name when installing Python 3 on Windows, and to my 
eye that is/was a _bad_ choice. I would like to see a good explaination 
as to why that choice was made.


Choosing Python 3 specificly is an important choice for many scripts 
because 2->3 was a breaking change.


Cheers,
Cameron Simpson 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6SIYM3OR2MHSRTW75I5ZG3N3VPOVWX5R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Barry Scott]

> On 25 Mar 2020, at 17:02, Andrew Barnert  wrote:
> 
> On Mar 25, 2020, at 05:02, Paul Moore  wrote:
>> 
>> The only reason anyone has ever suggested versioned executables on
>> Windows is for Unix compatibility - the reasons they are needed on
>> Unix simply don't apply on Windows (at least not in my experience -
>> it's possible that some peoplehave workflows that need versioned
>> executables, rather than simply using absolute paths or the launcher).
> 
> The obvious exception is exactly the one the OP has: they work primarily in 
> Cygwin, but use native Windows rather than Cygwin Python, so it’s Cygwin bash 
> scripts (and Linux-familiar users at the Cygwin shell) launching Python. In 
> that case, the reasons they’re needed on Unix do apply.

Either a bash alias or a bash script called python3 that runs py.exe with the 
right args is surely the fix?

alias python3='/mnt/c/WINDOWS/py -3'

I tested that in cygwin and it works fine.

Only odd thing I noticed is that to get a REPL I have to call as "py -3 -i" 
from cygwin.

> However, I’m pretty sure the traditional answer for that use case has always 
> been to use Cygwin Python, which I’d assume (it’s been nearly a decade since 
> I’ve dealt with this…) follows the Python-on-Unix naming PEP as well as 
> whichever linux distro inspires its packaging.


Not if you need to get a Windows APIs and services it is not an answer.

I think solutions are available without changes to python for the OPs problem.

Barry
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/S6KIZCFNOXJM4FKAEBTPBXGAHG4OGRAH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Brett Cannon]

On Wed, Mar 25, 2020 at 9:57 AM Paul Moore  wrote:

> On Wed, 25 Mar 2020 at 16:10, Eryk Sun  wrote:
>
> > The py launcher's "env" command searches PATH for anything from
> > "python" to "notepad" -- but not for a versioned Python command such
> > as "python3" or "python2".  It always uses a registered installation
> > in this case, which is at the very least problematic when using
> > "#!/usr/bin/env python3" in an active virtual environment. Paul Moore
> > will probably suggest that the script should use "#!/usr/bin/env
> > python" instead,
>
> Nope, I agree with your point about that running 2.x on Unix.
>
> IMO, the /usr/bin/python* and /usr/bin/env aliases are for Unix
> compatibility and so should prioritise that - but because Windows
> python doesn't include versioned executables, it's not always easy to
> do that.
>
> > but that will run 2.x in most Unix systems unless a
> > 3.x environment is active. We can assume that such a script requires
> > 3.x and is meant to run flexibly, in or out of an active environment.
>
> In principle I agree, but I'm not sure how you see that working in
> practice. If you have an activated venv, `#!/usr/bin/env python3`
> should use the venv Python or the system Python depending on whether
> the venv is Python 3 or not. But the only way of finding that out in
> the absence of versioned executables is running `python -V`. That's a
> performance hit that I'd rather we avoided.
>
> [see below about pyvenv.cfg - tl;dr is that there's no *documented*
> version info in there]
>
> > I'd prefer a consistent implementation of the "env" command that
> > doesn't special case versioned "pythonX[.Y]" commands compared to
> > plain "python". But another option that will at least make
> > virtual-environment users happy would be for "env" to check for an
> > active VIRTUAL_ENV and read its Python version from "pyvenv.cfg".
>
> I'd agree with that, if we had versioned executables. Without them, I
> honestly don't know what answer would cause the fewest issues, so I
> tend to assume that sticking with what we have is good enough, because
> we're not getting lots of complaints (we get some, but not that many).
>
> Following on from my comment above about needing to run `python -V`,
> I'd completely forgotten that pyvenv.cfg held the version statically
> nowadays.
>
> But virtualenv 20.0 and later writes a pyvenv.cfg with different
> information, and virtualenv < 20.0 doesn't write pyvenv.cfg at all.
> I'm OK with discounting old versions of virtualenv, but realistically,
> I believe that not interoperating with current versions of virtualenv
> is impractical. I think that if we want to rely on pyvenv.cfg, we
> should document/standardise its contents. At the moment, the docs only
> mention `home` and `include-system-site-packages`, and to be honest
> they sound more informational than normative anyway.
>

3.9 adds "prompt" to record any custom prompt that was specified.


>
> Unfortunately, there doesn't seem to be any real interest in
> standardising virtual environments at the moment.


I have interest. :)


> So for now, at
> least, it's difficult to see how the launcher can behave as you want
> (I assume it's obvious that we don't want to hard-code implementation
> details of virtualenv into the launcher).


Up to this point the only thing the Launcher has is support for when the
VIRTUAL_ENV environment variable is defined (my hope to standardize on
environment naming seems to have stalled out).


> I'd support a
> standardisation effort, but I don't intend to champion such an effort
> myself.
>

I don't either ATM, but maybe someday.


>
> Just to reiterate, I'd like a better, more uniform solution here. But
> I think there's more complexity than people are assuming, at least if
> we want to interoperate with 3rd party tools (which I view as
> necessary, although I guess others may take a more hard-line stance).
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6YFTKDP7AAEIOKNSR2F6TK64XS57VKV4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Paul Moore]

On Thu, 26 Mar 2020 at 15:52, Barry Scott  wrote:
>
> > On 25 Mar 2020, at 16:53, Paul Moore  wrote:
> >
> > On Wed, 25 Mar 2020 at 16:10, Eryk Sun  wrote:
> >
> >> The py launcher's "env" command searches PATH for anything from
> >> "python" to "notepad" -- but not for a versioned Python command such
> >> as "python3" or "python2".  It always uses a registered installation
> >> in this case, which is at the very least problematic when using
> >> "#!/usr/bin/env python3" in an active virtual environment. Paul Moore
> >> will probably suggest that the script should use "#!/usr/bin/env
> >> python" instead,
> >
> > Nope, I agree with your point about that running 2.x on Unix.
>
> At least on Fedora python is python3 now.
>
> On Centos 8 there is no python until you use the alternatives mechanism
> to set it as python2 or python3.

... which is probably more evidence in favour of some sort of point,
but at this stage I have no idea what, unless it's "nothing is
consistent and you need to be prepared to deal with cross-platform
differences" :-)

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/7A2KPOICNOHVLXIICMG4IQO3HDLCYIJN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Barry Scott]

> On 25 Mar 2020, at 16:53, Paul Moore  wrote:
> 
> On Wed, 25 Mar 2020 at 16:10, Eryk Sun  wrote:
> 
>> The py launcher's "env" command searches PATH for anything from
>> "python" to "notepad" -- but not for a versioned Python command such
>> as "python3" or "python2".  It always uses a registered installation
>> in this case, which is at the very least problematic when using
>> "#!/usr/bin/env python3" in an active virtual environment. Paul Moore
>> will probably suggest that the script should use "#!/usr/bin/env
>> python" instead,
> 
> Nope, I agree with your point about that running 2.x on Unix.

At least on Fedora python is python3 now.

On Centos 8 there is no python until you use the alternatives mechanism
to set it as python2 or python3.

Barry


> 
> IMO, the /usr/bin/python* and /usr/bin/env aliases are for Unix
> compatibility and so should prioritise that - but because Windows
> python doesn't include versioned executables, it's not always easy to
> do that.
> 
>> but that will run 2.x in most Unix systems unless a
>> 3.x environment is active. We can assume that such a script requires
>> 3.x and is meant to run flexibly, in or out of an active environment.
> 
> In principle I agree, but I'm not sure how you see that working in
> practice. If you have an activated venv, `#!/usr/bin/env python3`
> should use the venv Python or the system Python depending on whether
> the venv is Python 3 or not. But the only way of finding that out in
> the absence of versioned executables is running `python -V`. That's a
> performance hit that I'd rather we avoided.
> 
> [see below about pyvenv.cfg - tl;dr is that there's no *documented*
> version info in there]
> 
>> I'd prefer a consistent implementation of the "env" command that
>> doesn't special case versioned "pythonX[.Y]" commands compared to
>> plain "python". But another option that will at least make
>> virtual-environment users happy would be for "env" to check for an
>> active VIRTUAL_ENV and read its Python version from "pyvenv.cfg".
> 
> I'd agree with that, if we had versioned executables. Without them, I
> honestly don't know what answer would cause the fewest issues, so I
> tend to assume that sticking with what we have is good enough, because
> we're not getting lots of complaints (we get some, but not that many).
> 
> Following on from my comment above about needing to run `python -V`,
> I'd completely forgotten that pyvenv.cfg held the version statically
> nowadays.
> 
> But virtualenv 20.0 and later writes a pyvenv.cfg with different
> information, and virtualenv < 20.0 doesn't write pyvenv.cfg at all.
> I'm OK with discounting old versions of virtualenv, but realistically,
> I believe that not interoperating with current versions of virtualenv
> is impractical. I think that if we want to rely on pyvenv.cfg, we
> should document/standardise its contents. At the moment, the docs only
> mention `home` and `include-system-site-packages`, and to be honest
> they sound more informational than normative anyway.
> 
> Unfortunately, there doesn't seem to be any real interest in
> standardising virtual environments at the moment. So for now, at
> least, it's difficult to see how the launcher can behave as you want
> (I assume it's obvious that we don't want to hard-code implementation
> details of virtualenv into the launcher). I'd support a
> standardisation effort, but I don't intend to champion such an effort
> myself.
> 
> Just to reiterate, I'd like a better, more uniform solution here. But
> I think there's more complexity than people are assuming, at least if
> we want to interoperate with 3rd party tools (which I view as
> necessary, although I guess others may take a more hard-line stance).
> 
> Paul
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/ITB4WDUWQD6KG7WPRJKTFAOG3TG5FQZS/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BP3TSQBIKVM23KBKKOT7NASZLDWNVIHP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Andrew Barnert via Python-ideas]

On Mar 25, 2020, at 05:02, Paul Moore  wrote:
> 
> The only reason anyone has ever suggested versioned executables on
> Windows is for Unix compatibility - the reasons they are needed on
> Unix simply don't apply on Windows (at least not in my experience -
> it's possible that some peoplehave workflows that need versioned
> executables, rather than simply using absolute paths or the launcher).

The obvious exception is exactly the one the OP has: they work primarily in 
Cygwin, but use native Windows rather than Cygwin Python, so it’s Cygwin bash 
scripts (and Linux-familiar users at the Cygwin shell) launching Python. In 
that case, the reasons they’re needed on Unix do apply.

However, I’m pretty sure the traditional answer for that use case has always 
been to use Cygwin Python, which I’d assume (it’s been nearly a decade since 
I’ve dealt with this…) follows the Python-on-Unix naming PEP as well as 
whichever linux distro inspires its packaging.

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/JJAAVW2Y5F6V26V5YBMLHAD5B2BVMNEP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Paul Moore]

On Wed, 25 Mar 2020 at 16:10, Eryk Sun  wrote:

> The py launcher's "env" command searches PATH for anything from
> "python" to "notepad" -- but not for a versioned Python command such
> as "python3" or "python2".  It always uses a registered installation
> in this case, which is at the very least problematic when using
> "#!/usr/bin/env python3" in an active virtual environment. Paul Moore
> will probably suggest that the script should use "#!/usr/bin/env
> python" instead,

Nope, I agree with your point about that running 2.x on Unix.

IMO, the /usr/bin/python* and /usr/bin/env aliases are for Unix
compatibility and so should prioritise that - but because Windows
python doesn't include versioned executables, it's not always easy to
do that.

> but that will run 2.x in most Unix systems unless a
> 3.x environment is active. We can assume that such a script requires
> 3.x and is meant to run flexibly, in or out of an active environment.

In principle I agree, but I'm not sure how you see that working in
practice. If you have an activated venv, `#!/usr/bin/env python3`
should use the venv Python or the system Python depending on whether
the venv is Python 3 or not. But the only way of finding that out in
the absence of versioned executables is running `python -V`. That's a
performance hit that I'd rather we avoided.

[see below about pyvenv.cfg - tl;dr is that there's no *documented*
version info in there]

> I'd prefer a consistent implementation of the "env" command that
> doesn't special case versioned "pythonX[.Y]" commands compared to
> plain "python". But another option that will at least make
> virtual-environment users happy would be for "env" to check for an
> active VIRTUAL_ENV and read its Python version from "pyvenv.cfg".

I'd agree with that, if we had versioned executables. Without them, I
honestly don't know what answer would cause the fewest issues, so I
tend to assume that sticking with what we have is good enough, because
we're not getting lots of complaints (we get some, but not that many).

Following on from my comment above about needing to run `python -V`,
I'd completely forgotten that pyvenv.cfg held the version statically
nowadays.

But virtualenv 20.0 and later writes a pyvenv.cfg with different
information, and virtualenv < 20.0 doesn't write pyvenv.cfg at all.
I'm OK with discounting old versions of virtualenv, but realistically,
I believe that not interoperating with current versions of virtualenv
is impractical. I think that if we want to rely on pyvenv.cfg, we
should document/standardise its contents. At the moment, the docs only
mention `home` and `include-system-site-packages`, and to be honest
they sound more informational than normative anyway.

Unfortunately, there doesn't seem to be any real interest in
standardising virtual environments at the moment. So for now, at
least, it's difficult to see how the launcher can behave as you want
(I assume it's obvious that we don't want to hard-code implementation
details of virtualenv into the launcher). I'd support a
standardisation effort, but I don't intend to champion such an effort
myself.

Just to reiterate, I'd like a better, more uniform solution here. But
I think there's more complexity than people are assuming, at least if
we want to interoperate with 3rd party tools (which I view as
necessary, although I guess others may take a more hard-line stance).

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ITB4WDUWQD6KG7WPRJKTFAOG3TG5FQZS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Eryk Sun]

On 3/25/20, Barry Scott  wrote:
>> On 25 Mar 2020, at 09:15, Eryk Sun  wrote:
>>
>> That is not consistent with Unix. env is supposed to search PATH for
>> the command. However, the launcher does not search PATH for a
>> versioned command such as "python3". Instead it uses the highest
>> version that's registered for 3.x or 2.x, respectively, or the version
>> set by PY_PYTHON3 or PY_PYTHON2 if defined, respectively.
>
> I think the reasoning is that the whole point of the py.exe is to avoid
> having users edit their PATH on Windows. And further the thinking
> goes that you do not need the alternatively named python programs.

The py launcher's "env" command searches PATH for anything from
"python" to "notepad" -- but not for a versioned Python command such
as "python3" or "python2".  It always uses a registered installation
in this case, which is at the very least problematic when using
"#!/usr/bin/env python3" in an active virtual environment. Paul Moore
will probably suggest that the script should use "#!/usr/bin/env
python" instead, but that will run 2.x in most Unix systems unless a
3.x environment is active. We can assume that such a script requires
3.x and is meant to run flexibly, in or out of an active environment.

I'd prefer a consistent implementation of the "env" command that
doesn't special case versioned "pythonX[.Y]" commands compared to
plain "python". But another option that will at least make
virtual-environment users happy would be for "env" to check for an
active VIRTUAL_ENV and read its Python version from "pyvenv.cfg".
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NEO6ZBIIGL2JWVG77SHUKNTWLY2ZFJ5G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Paul Moore]

On Wed, 25 Mar 2020 at 11:43, Barry Scott  wrote:
> I think the reasoning is that the whole point of the py.exe is to avoid having
> users edit their PATH on Windows. And further the thinking goes that
> you do not need the alternatively named python programs.

The alternatively named programs have never been needed on Windows
because the issue that prompted needing them on Unix (system scripts
that referred to "/usr/bin/python" expecting to get Python 2) didn't
exist on Windows. The py launcher was introduced to support file
associations for .py[w] files, and to support shebangs. It became
common as a command line utility because it's convenient to not need
to edit PATH.

The relevant PEPs for the history are PEP 397 for the launcher and PEP
394 for the background on versioned names on Unix (although I'm not
sure all distros actually follow PEP 394...)

The only reason anyone has ever suggested versioned executables on
Windows is for Unix compatibility - the reasons they are needed on
Unix simply don't apply on Windows (at least not in my experience -
it's possible that some peoplehave workflows that need versioned
executables, rather than simply using absolute paths or the launcher).

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4VTKCFES2IFJKLZQGYRFUU3U6GC7XCRK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Barry Scott]

> On 25 Mar 2020, at 09:15, Eryk Sun  wrote:
> 
> On 3/25/20, Steve Barnes  wrote:
>>> Except it's not necessarily what the original post wants. The OP wants the
>>> shebang "#!/usr/bin/env python3" to "work everywhere by
>>> default", for which I assume it's implied that it should work consistently
>>> everywhere. I'd prefer for the launcher's env search to also
>>> support versioned "pythonX[.Y][-32|-64]" commands such as "python3".
>> 
>> The windows launcher already does support this with shebangs of:
>> #!/usr/bin/env python3 # Launch with the latest/preferred version of python3
>> #!/usr/bin/env python2 # Launch with the latest/preferred version of python2
> 
> That is not consistent with Unix. env is supposed to search PATH for
> the command. However, the launcher does not search PATH for a
> versioned command such as "python3". Instead it uses the highest
> version that's registered for 3.x or 2.x, respectively, or the version
> set by PY_PYTHON3 or PY_PYTHON2 if defined, respectively.

I think the reasoning is that the whole point of the py.exe is to avoid having
users edit their PATH on Windows. And further the thinking goes that
you do not need the alternatively named python programs.

Is that your understanding as well Eryk?

Barry

> 
>> #!/usr/bin/env python # Launch with the latest/preferred version of python 2
>> unless PY_PYTHON=3[.n[-64/32]] is set or py.ini has the same in.
> 
> In this case "env" first searches PATH before falling back on
> registered installations and PY_PYTHON, which is correct -- at least
> for the PATH search. I would prefer that "env" never checks registered
> installations. For the registry fallback, it should instead check the
> user and system "App Paths" key, like what ShellExecuteExW does.
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/YX4DOI4MWTB7AVL4QMT5EN4TQBNRSHEZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WPYJ35CYXW7OITXPQ2DBC7X6HRBQHXI5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Eryk Sun]

On 3/25/20, Steve Barnes  wrote:
>> Except it's not necessarily what the original post wants. The OP wants the
>> shebang "#!/usr/bin/env python3" to "work everywhere by
>> default", for which I assume it's implied that it should work consistently
>> everywhere. I'd prefer for the launcher's env search to also
>> support versioned "pythonX[.Y][-32|-64]" commands such as "python3".
>
> The windows launcher already does support this with shebangs of:
> #!/usr/bin/env python3 # Launch with the latest/preferred version of python3
> #!/usr/bin/env python2 # Launch with the latest/preferred version of python2

That is not consistent with Unix. env is supposed to search PATH for
the command. However, the launcher does not search PATH for a
versioned command such as "python3". Instead it uses the highest
version that's registered for 3.x or 2.x, respectively, or the version
set by PY_PYTHON3 or PY_PYTHON2 if defined, respectively.

> #!/usr/bin/env python # Launch with the latest/preferred version of python 2
> unless PY_PYTHON=3[.n[-64/32]] is set or py.ini has the same in.

In this case "env" first searches PATH before falling back on
registered installations and PY_PYTHON, which is correct -- at least
for the PATH search. I would prefer that "env" never checks registered
installations. For the registry fallback, it should instead check the
user and system "App Paths" key, like what ShellExecuteExW does.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YX4DOI4MWTB7AVL4QMT5EN4TQBNRSHEZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Eryk Sun]

On 3/25/20, Steve Barnes  wrote:
> Of course if, rather than creating symlinks, you create a batch file called
> python3.bat and containing the line:
> @py -3 %*

Batch scripts execute via cmd.exe, with an attached console, and when
Ctrl+C is typed they display a "Terminate batch job (Y/N)?" prompt
when cmd.exe resumes. This makes them a poor substitute for a link.

If the link is created beside "py.exe", it's better to use a relative
symlink. If the link is in another directory, use a shell link (i.e.
shortcut). Set the command to run as "C:\Windows\py.exe -3", or
wherever "py.exe" is installed. The shell API will pass command line
arguments. Clear the shortcut's "start in" field in order to inherit
the parent's working directory. Add ".LNK" to PATHEXT to be able to
run "python3" on the command line instead of requiring "python3.lnk".

> It is also worth mentioning that python (and the py launcher) both accept
> windows paths (\ separated) and *nix paths (/ separated) from the command
> line and that from within scripts the *nix path separator is to be preferred

That's generally true. Note however that the only reliable way to
access a path that exceeds MAX_PATH characters (260, or less depending
on context) is with a \\?\ extended path, which must use backslash.
(Python 3.6+ does support long normal paths in Windows 10, but this
capability has to be enabled at the system level. Plus many scripts
and applications still need to support Windows 7 and 8.)

An extended path is also required to open files with certain reserved
names such as DOS devices (e.g. "con" or "nul:.txt") and names that
end with spaces and dots (e.g. "spam. . ."). But please do not use an
extended path in order to assign reserved names. It just causes
needless problems.

> glob.glob("C:/Users/Gadget/Documents/*.docx") - the only real issue to avoid
> is the fact that Windows paths are case insensitive so names that differ
> only in case changes can & will collide.

A FAT32 filesystem is case insensitive in Unix (e.g. on a portable
drive), so this problem isn't limited to Windows. It's just more
common in Windows.

Also, an NTFS directory tree can be flagged as case sensitive in
Windows 10, but thankfully this isn't commonly used, even by
developers.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HHOB2HGK7AN7ZATWAS2GPBMN3CDOLGKY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Eryk Sun]

On 3/24/20, Mike Miller  wrote:
> On 2020-03-24 11:58, Eryk Sun wrote:
>
>> You can manually copy or symlink python.exe to python3.exe in the
>> installation directory and venv "Scripts" directories. However, it
>> will only be used on the command line, and other contexts that search
>> PATH. Currently the launcher will not use it with a virtual "env"
>> shebang. The launcher will search PATH for "python", but not
>> "python3".
>
> Thanks.  Sure, there are many ways to fix this manually, or work around it.

Except it's not necessarily what the original post wants. The OP wants
the shebang "#!/usr/bin/env python3" to "work everywhere by default",
for which I assume it's implied that it should work consistently
everywhere. I'd prefer for the launcher's env search to also support
versioned "pythonX[.Y][-32|-64]" commands such as "python3".

I'd also prefer the env search to check the user and system "App
Paths" key [1] if the name isn't found in PATH. Each subkey of "App
Paths" is the name of a command such as "python3.exe", for which the
fully-qualified executable filename is the key's default value. This
is the Windows shell API equivalent of creating symlinks in
"~/.local/bin" and "/usr/bin" on Unix systems. ShellExecuteExW checks
"App Paths", but the launcher has to use CreateProcessW, which is
beneath the shell API.

> Would be great if it was consolidated, with one command "to rule them all."

I'm in favor of "py" becoming the cross-platform command to run Python
from the command line, since there's already a lot of inertia in that
direction on Windows. Brett Cannon is working on a Unix version [2].

[1]: 
https://docs.microsoft.com/en-us/windows/win32/shell/app-registration#using-the-app-paths-subkey
[2]: https://crates.io/crates/python-launcher
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VHHZ263OEMNISHMBTPPTC7OVYJNA4KIO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Steve Barnes]

Of course if, rather than creating symlinks, you create a batch file called 
python3.bat and containing the line:
@py -3 %*
Then save it to somewhere on your path, e.g. the python scripts directory, then 
issuing, from the command line or another batch file the command python3 should 
just work (as long as the chosen location is earlier in the path than 
%appdata%\..\Local\Microsoft\WindowsApps\ which is where the python3.exe app 
store launcher lives). 

As the py launcher works just find in MinGW you can either do the same with a 
bash script or an alias and the Windows System For Linux allows you to install 
python3 as well as python (on my system the latest versions are 3.5.1-3 & 
2.7.12-1).

It is also worth mentioning that python (and the py launcher) both accept 
windows paths (\ separated) and *nix paths (/ separated) from the command line 
and that from within scripts the *nix path separator is to be preferred as it 
will not require either being in a r-string or escaped i.e. you can use 
glob.glob(r"C:\Users\Gadget\*.docx") or 
glob.glob("C:\\Users\\Gadget\\Documents\\*.docx") but are better off using 
glob.glob("C:/Users/Gadget/Documents/*.docx") - the only real issue to avoid is 
the fact that Windows paths are case insensitive so names that differ only in 
case changes can & will collide.

-Original Message-
From: Mike Miller  
Sent: 24 March 2020 21:39
To: python-ideas@python.org
Subject: [Python-ideas] Re: About python3 on windows


On 2020-03-24 11:58, Eryk Sun wrote:
> On 3/24/20, Mike Miller  wrote:
>>
>>   C:\Users\User>python3
>>   (App store loads!!)
> 
> If installed, the app distribution has an appexec link for 
> "python3.exe" that actually works.
> 
>>   C:\Python38>dir
>>Volume in drive C has no label.
>> [snip]
>> Note there is no python3.exe binary.
> 
> You can manually copy or symlink python.exe to python3.exe in the 
> installation directory and venv "Scripts" directories. However, it 
> will only be used on the command line, and other contexts that search 
> PATH. Currently the launcher will not use it with a virtual "env"
> shebang. The launcher will search PATH for "python", but not 
> "python3".


Thanks.  Sure, there are many ways to fix this manually, or work around it. 
Would be great if it was consolidated, with one command "to rule them all."
___
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an 
email to python-ideas-le...@python.org 
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F2NEZJXKW4HAZUMXC4IW27KIMT67Y4VN/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PRZ6OOSU74FXHR225ZMYCHVXDXG2LAAK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Mike Miller]

On 2020-03-24 11:58, Eryk Sun wrote:

On 3/24/20, Mike Miller  wrote:


  C:\Users\User>python3
  (App store loads!!)


If installed, the app distribution has an appexec link for
"python3.exe" that actually works.


  C:\Python38>dir
   Volume in drive C has no label.
[snip]
Note there is no python3.exe binary.


You can manually copy or symlink python.exe to python3.exe in the
installation directory and venv "Scripts" directories. However, it
will only be used on the command line, and other contexts that search
PATH. Currently the launcher will not use it with a virtual "env"
shebang. The launcher will search PATH for "python", but not
"python3".



Thanks.  Sure, there are many ways to fix this manually, or work around it. 
Would be great if it was consolidated, with one command "to rule them all."

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/F2NEZJXKW4HAZUMXC4IW27KIMT67Y4VN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Chris Angelico]

On Wed, Mar 25, 2020 at 7:29 AM Christopher Barker  wrote:
>
> On Mon, Mar 23, 2020 at 6:19 PM Oleg Broytman  wrote:
>>
>>
>> IMO the issue is in not following the best practices. Distribute wheels
>> or freezed binaries, not just drop scripts unto users.
>
>
> This is a good point, though I’m not sure the best solution. Frozen Binaries 
> (py2exe, PyInstaller) are a good solution if you have one or two 
> applications. But if you have a a whole bunch of small scripts, then each one 
> would have a full copy of Python -- not ideal.
>

Extremely unideal, since then it's the app publisher's responsibility
to keep on top of Python version updates and rebundle.

> 2) Provide clear instructions for users: and they WILL be different on 
> Windows and *nix.
>   - I got the impression that one problem was finger memory for users of 
> multiple OSs -- I have this problem, too. In that case, you could also make a 
> copy of py.exe. and name it python3.exe -- problem solved :-)
>  (now that i think about it, is there any reason cPython couldn't' install a 
> set of aliases (or copies, or links, or) to the py launcher called "python" 
> and "python3" ?
>

Aliasing py as python and python3 would be great, as long as that
doesn't introduce bizarrenesses of any sort. That would also work for
scripts (makefiles, 'npm run blah', etc), which AIUI was the OP's main
issue.

> 3) In scripts that can only be run in Python3, have a little check at the top 
> that makes sure it's being run in Python3, and give a meaningful message if 
> it's not:
>
>  if sys.version_info.major != 3:
> print("You are not running the correct version of Python: please install 
> Python3,"
>   "and run this script with:\n"
>   "
> )
>
> That leaves open the Python-ideas part of this: should the standard Python 
> installers do anything different than they do?
>

What I would really like would be for Windows to ship with a
"python.exe" and a "python3.exe" that inform the user that the script
requested requires Python, please install it from the app store. And
if it IS installed, just exec straight into py. But I'm sure this
would cause other issues somewhere.

ChrisA
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/K7PGCQPF6CBONJOEW5NTXFTVGO3UOZEG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Christopher Barker]

On Mon, Mar 23, 2020 at 6:19 PM Oleg Broytman  wrote:

>
> IMO the issue is in not following the best practices. Distribute wheels
> or freezed binaries, not just drop scripts unto users.
>

This is a good point, though I’m not sure the best solution. Frozen
Binaries (py2exe, PyInstaller) are a good solution if you have one or two
applications. But if you have a a whole bunch of small scripts, then each
one would have a full copy of Python -- not ideal.

So what about wheels? That may be a good way to go. wheels are a complete
package bundled up that can be installed into the Python environment. And
that can include scripts. So you should be able to install a wheel into the
correct Python, and then have access to scripts. The trick is that the user
needs to know how to install that wheel, and they need to install it into
the "right" python. `pip install the_wheel` is only going to work if its
the right pip. and `python -m pip install the_wheel` has all the same
problems that the OP's concerned about here. However, that is a one-time
issue -- you get your users to install the wheel correctly, and then they
have access to the script without anything special from there. And you
could probably make an installer that would install it in the right place
automatically (I know that back in the day, we were looking at associating
an app with wheels on the Mac, so they could be point and clicked on and
get installed -- one could do that for Windows, yes?

But back to the OP's issue: Python can be considered a "scripting"
language, and it IS useful when used that way, for smaller utilities that
don't have a lot of dependencies, etc. And it is nice to be able to
just drop a script somewhere and run it. And that works well on *nix
systems -- just set the #! line and away you go.

But in a cross platform environment, there are two key problems:

1) Windows works differently than *nix, but at a fundamental level (no #!
line, different handling of PATH) and on a conventional level -- there
simply isn't the same isn't the same culture of command line use.

Given (1) Python had to do something differently on Windows than *nix (and
the Mac, though that's converged more now), which brings us to problem (2)

2) The Python community came up with solutions for each platform that made
sense for that platform: the conventions for *nix, and the py.exe launcher
for Windows. But there was little effort made to make the user experience
the SAME on all platforms. Personally, I think that's a shame, as Brett
pointed out, there's no reason you couldn't have a "py" launcher on *nix,
and there's no reason you couldn't have a "python3" alias on Windows
installs.

Whether that would be a good idea is debatable, the platforms are
different, the user base is different: could *nix users use a py launcher
anyway? Would Windows users want to put "python3" on their PATH? (or know
how to?).

There was a pretty involved discussion about this about a year ago (?) --
which I think led to Brett deciding to give a py launcher for *nix a
chance. I *think* it was on python-dev. But interested parties should go
look for it.

There is also the problem that as time has gone no, PEP 394 (
https://www.python.org/dev/peps/pep-0394/) was created in 2011 -- the
python world has changed: there are more systems with only Python3, and
there are various virtual environment systems, like conda, that manage the
entire environment, so there's a whole new way to manage which Python
version to use. (though conda, at least, does provide a "python3" command
-- I wonder if it does on Windows?) So I'm not sure the PEP 394.

But back to the OP's problem: what to do now? My suggestions for options:

1) Have a "standard" python install for your users, and use wheels to
distribute your scripts. That actually has the advantage that you can put a
library in there, and multiple scripts, and all sorts of nifty stuff. It
might be nicer to bundle up related scripts anyway.
 - wheels can be tagged with Python version, so it can't be installed into
the wrong one.

2) Provide clear instructions for users: and they WILL be different on
Windows and *nix.
  - I got the impression that one problem was finger memory for users of
multiple OSs -- I have this problem, too. In that case, you could also make
a copy of py.exe. and name it python3.exe -- problem solved :-)
 (now that i think about it, is there any reason cPython couldn't' install
a set of aliases (or copies, or links, or) to the py launcher called
"python" and "python3" ?

3) In scripts that can only be run in Python3, have a little check at the
top that makes sure it's being run in Python3, and give a meaningful
message if it's not:

 if sys.version_info.major != 3:
print("You are not running the correct version of Python: please
install Python3,"
  "and run this script with:\n"
  "
)

That leaves open the Python-ideas part of this: should the standard Python
installers do anything different than they do?

[Python-ideas] Re: About python3 on windows

[Kyle Stanley]

> The Microsoft Store version does not offer any options full stop!

Good to know, thanks for clarifying. I haven't personally installed it from
the Microsoft app store, but it was my assumption that it did not allow for
custom installation options.

On Tue, Mar 24, 2020 at 3:18 PM Steve Barnes  wrote:

> https://docs.python.org/3.8/using/windows.html#installing-without-ui
> gives details of all of the options. The Microsoft Store version does not
> offer any options full stop!
>
>
>
> *From:* Kyle Stanley 
> *Sent:* 24 March 2020 18:10
> *To:* Frédéric De Jaeger 
> *Cc:* Python-ideas < >
> *Subject:* [Python-ideas] Re: About python3 on windows
>
>
>
> > That would be nice.  Does it apply to the _windows store version_,  the
> _traditional installer_, both ?
>
>
>
> I believe it only applies to the traditional installer from python.org.
> You will also have to verify it, as it has been a decent while since I've
> had to install Python on Windows.
>
>
>
> On Tue, Mar 24, 2020 at 7:05 AM Frédéric De Jaeger <
> fdejae...@novaquark.com> wrote:
>
> > Windows devices, they might want to consider using the PrependPath option
> > (which adds Python to PATH from the command line). I.E.
> > python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1
> > (IIRC, the above installation should allow usage of "python3" on
> > Windows for all users on the device)
>
> That would be nice.  Does it apply to the _windows store version_,  the
> _traditional installer_, both ?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/WQFJ4YGNUCKBITTHZQCME3GQRXPVPYT2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/ZEY7LXEGPKBRCO6RBSSFSQ2W2F7ZLOI6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Steve Barnes]

https://docs.python.org/3.8/using/windows.html#installing-without-ui gives 
details of all of the options. The Microsoft Store version does not offer any 
options full stop!

From: Kyle Stanley 
Sent: 24 March 2020 18:10
To: Frédéric De Jaeger 
Cc: Python-ideas < >
Subject: [Python-ideas] Re: About python3 on windows

> That would be nice.  Does it apply to the _windows store version_,  the 
> _traditional installer_, both ?

I believe it only applies to the traditional installer from 
python.org<http://python.org>. You will also have to verify it, as it has been 
a decent while since I've had to install Python on Windows.

On Tue, Mar 24, 2020 at 7:05 AM Frédéric De Jaeger 
mailto:fdejae...@novaquark.com>> wrote:
> Windows devices, they might want to consider using the PrependPath option
> (which adds Python to PATH from the command line). I.E.
> python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1
> (IIRC, the above installation should allow usage of "python3" on
> Windows for all users on the device)

That would be nice.  Does it apply to the _windows store version_,  the 
_traditional installer_, both ?
___
Python-ideas mailing list -- 
python-ideas@python.org<mailto:python-ideas@python.org>
To unsubscribe send an email to 
python-ideas-le...@python.org<mailto:python-ideas-le...@python.org>
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WQFJ4YGNUCKBITTHZQCME3GQRXPVPYT2/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YOJNE46ZO35G44TRSVKUTQQHWQCEVFMI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Eryk Sun]

On 3/24/20, Mike Miller  wrote:
>
>  C:\Users\User>python3
>  (App store loads!!)

If installed, the app distribution has an appexec link for
"python3.exe" that actually works.

>  C:\Python38>dir
>   Volume in drive C has no label.
> [snip]
> Note there is no python3.exe binary.

You can manually copy or symlink python.exe to python3.exe in the
installation directory and venv "Scripts" directories. However, it
will only be used on the command line, and other contexts that search
PATH. Currently the launcher will not use it with a virtual "env"
shebang. The launcher will search PATH for "python", but not
"python3".
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6U64JXGJZ4TFTCXJ6X636AYI5QYQLVMX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Mike Miller]

On 2020-03-23 16:49, Brett Cannon wrote:

Recently I've had to use a Windows VM for some stuff at work, where I 
installed
Python 3 as well.  Every time I type python3 at the command-line (instead of
python) to use the repl, it tries to load the Microsoft App Store!


There is an option to install Python to PATH on Windows if you check the 
appropriate box during installation, but that's not really the way Windows apps 
typically work.



I realize why that was done, to help out newbies, but it is not what I want 
at
all.  Not the end of the world, but some consistency would be nice.


As I said, you can install Python to PATH on Windows if you choose.



Was pretty sure I did that and just checked.

Here is the result, backwards from Ubuntu, if you'd like to run Python3:


Microsoft Windows [Version 10.0.18363.720]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\User>path

PATH=C:\Python38\Scripts\;C:\Python38\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\
System32\OpenSSH\;C:\Program Files\PuTTY\;C:\Program Files\Yori;C:\Program 
Files\Yori;C:\Users\User\AppData\Local\Microsoft\WindowsApps;;C:\Users\User

\AppData\Local\Programs\Microsoft VS Code\bin

C:\Users\User>python
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 
bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> ^Z

C:\Users\User>python3

(App store loads!!)

C:\Users\User>cd \Python38

C:\Python38>dir
 Volume in drive C has no label.
 Volume Serial Number is 4A31-C9FC

 Directory of C:\Python38

2019-12-07  05:40 PM  .
2019-12-07  05:40 PM  ..
2019-12-07  05:40 PM  DLLs
2019-12-07  05:40 PM  Doc
2019-12-07  05:39 PM  include
2019-12-07  05:40 PM  Lib
2019-12-07  05:39 PM  libs
2019-10-14  08:43 PM31,322 LICENSE.txt
2019-10-14  08:44 PM   866,080 NEWS.txt
2019-10-14  08:43 PM99,912 python.exe
2019-10-14  08:43 PM58,952 python3.dll
2019-10-14  08:43 PM 4,183,112 python38.dll
2019-10-14  08:43 PM98,376 pythonw.exe
2020-03-17  03:01 PM  Scripts
2019-12-07  05:40 PM  Tools
2019-10-14  08:43 PM89,752 vcruntime140.dll
   7 File(s)  5,427,506 bytes
   9 Dir(s)  108,736,249,856 bytes free


Note there is no python3.exe binary.

-Mike
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/SHJ5ANUQKNFJ5P74LX3SPOVIHQOTXLPK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Kyle Stanley]

> That would be nice.  Does it apply to the _windows store version_,  the
_traditional installer_, both ?

I believe it only applies to the traditional installer from python.org. You
will also have to verify it, as it has been a decent while since I've had
to install Python on Windows.

On Tue, Mar 24, 2020 at 7:05 AM Frédéric De Jaeger 
wrote:

> > Windows devices, they might want to consider using the PrependPath option
> > (which adds Python to PATH from the command line). I.E.
> > python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1
> > (IIRC, the above installation should allow usage of "python3" on
> > Windows for all users on the device)
>
> That would be nice.  Does it apply to the _windows store version_,  the
> _traditional installer_, both ?
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/WQFJ4YGNUCKBITTHZQCME3GQRXPVPYT2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VHVGN6UWENOKG2LT37C4APGRFXCKOKTL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Eryk Sun]

On 3/24/20, Barry Scott  wrote:
>
> If you have python 2 and 3 installed then
>
>py -3 myscript

"myscript" may have a shebang that runs the "python2" virtual command
(e.g. "#!python2" or "#!/usr/bin/python2") because the script requires
2.x, but using "-3" will override it to run the "python3" virtual
command instead.

The "python2" virtual command defaults to the highest installed
version of 2.x. The "python3" virtual command defaults to the highest
installed version of 3.x. Without a shebang, the "python" virtual
command defaults to the highest installed 3.x, but with a shebang it
defaults to the highest installed 2.x. py without a script (e.g. the
REPL or -c or -m) uses the "python" virtual command, so it defaults to
the highest installed 3.x.

The version to run for the "python" virtual command is set via the
PY_PYTHON environment variable, whether or not there's a shebang.
Similarly the version to run for the "python2" and "python3" virtual
commands is set via PY_PYTHON2 and PY_PYTHON3. No sanity checks are
performed, so "PY_PYTHON2=3" is allowed.

>> #! /usr/bin/env python3
>
> This does work out of the box because py.exe is run when you execute a .py
> in the CMD.

The "/usr/bin/env" virtual command is expected to search PATH. py does
search PATH for "/usr/bin/env python", but for "/usr/bin/env python3"
it uses the "python3" virtual command instead of searching, since
standard Python installations and virtual environments do not include
"python3.exe". There's an open issue for this, but there's no
consensus.

> You can check by doing:
>
> assoc .py
> ftype Python.File
>
> If Python.File is not using py.exe then you can fix that with this command
> from an Admin CMD.
>
> ftype Python.File="C:\windows\py.exe" "%1" %*

CMD's internal assoc and ftype commands are no longer useful in
general. They date back to Windows NT 4 (1996) and have never been
updated. As far as I know, Microsoft has no up-to-date, high level
commands or PowerShell cmdlets to replace assoc and ftype. In
PowerShell I suppose you could pInvoke the shell API (e.g.
AssocQueryStringW).

assoc and ftype only access the basic system file types and progids in
"HKLM\Software\Classes", not the HKCR view that merges in and prefers
"HKCU\Software\Classes" or various other subkeys such as
"Applications" and "SystemFileAssociations". Also, they don't account
for the cached and locked user choice in the shell.

For example, assoc may tell you that ".py" is associated with the
"Python.File" progid. But it's potentially wrong. It's not aware of an
association set in "HKCU\Software\Classes\.py" (e.g. set by a per-user
Python installation). It's also not aware of a locked-in user choice
(i.e. the user selected to always use a particular app), if one is
set, in 
"HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\UserChoice".

The user should set the file association using the settings dialog for
choosing default apps by file type or the "open with" dialog on the
right-click context menu. If the application chooser doesn't include a
Python icon with a rocket on it, then probably the launcher and
Python.File progid are installed for all users, but there's a per-user
association in "HKCU\Software\Classes\.py" that's overriding the
system setting. Deleting the default value in the latter key should
restore the launcher to the list of choices.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/C3ZH4TZLN3APOF3PVSEEZM6XIVCIIFVG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Frédéric De Jaeger]

>  This does work out of the box because py.exe is run when you execute a .py 
> in the
> CMD.

Yep, but the constraint is it has to run in Cygwin's bash terminal.   Does it 
honor windows file associations ?  I have some doubts (sorry I don't have a 
windows available to test the hypothesis).  If it works, this is a valid 
solution.

Probably the best option for us is to install python via Cygwin, as already 
suggested.We are in a kind of no man's land playing with Cygwin and pure 
windows python packages and expecting the linux behavior.  I imagine this is 
the reason why people don't complain that much about it.
Python is not critical in our business, the problem went largely unnoticed 
until our scripts become complicated enough and started to use python3 only 
features.  

Fred
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NGWW3JZXKUIVPU4C3EM5Y5RYRAPOZ5EJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Paul Moore]

On Tue, 24 Mar 2020 at 11:39, Eric V. Smith  wrote:
> Cygwin should make it easier to have Windows look like Unix, not harder.

In my experience, only if you use Cygwin for everything (so I agree,
Frédéric should probably install cygwin Python). Integrating native
applications and Cygwin isn't hard, but it's not seamless, either (and
honestly, that shouldn't really be surprising to anyone - Unix and
Windows are very different environments, after all).

There's also the option (if Frédéric's users are on Windows 10) of
using Ubuntu on Windows for a 100% compatible Unix environment.

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5VXCBGPACTBNA5GD7PPZ32UTS5FACZGH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Paul Moore]

On Tue, 24 Mar 2020 at 09:41, Rhodri James  wrote:
>
> On 24/03/2020 01:13, Oleg Broytman wrote:
> > IMO the issue is in not following the best practices. Distribute wheels
> > or freezed binaries, not just drop scripts unto users.
>
> For most circumstances, that is not a practical answer.  Creating wheels
> or frozen binaries are subjects that most Python programmers know little
> about and care less about.  Expecting someone to learn how to wield the
> packaging system just to do internal distribution is unrealistic.

Agreed (and I speak as a packaging specialist!) We shouldn't be
promoting something as heavyweight as building wheels or freezing a
whole Python application just to share scripts between colleagues.

I think the advice to use shebang lines in scripts, and run those
scripts directly on Unix, and via the py launcher (or using the .py
filetype association with the launcher) is about right. It's not 100%
seamless, and it does need some level of configuration and setup on
the machines that are expected to run the scripts - and you need to
manually manage any package dependencies for yourself - but I think
it's sufficient.

On Tue, 24 Mar 2020 at 11:00, Frédéric De Jaeger
 wrote:
> One of our constraint is that we use Cygwin's bash and now, every user relies 
> on the shebang.

Cygwin is an additional level of complexity. It attempts to provide a
"Unix-like" environment on Windows - and it does a very good job of
that! But it *isn't* Unix, and so there are differences. Expecting two
completely different operating systems to behave identically is, IMO,
a bit optimistic. You really need to be able to assume a base level of
knowledge from your users (or you have to go down the route of
bundling Python scripts into standalone "no knowledge required"
applications). To me, that base level of knowledge would be "the user
knows how to run a Python script". But I understand that this is
basically the point of your question.

Conversely, if I handed your users a Ruby script (or a Perl script, or
a Javascript program) - would they be able to run them with no
additional knowledge? I don't think the problem you have here is
unique to Python, it's equally applicable to any language with a
runtime that needs to be installed and invoked.

> The problem reduce to this.  Assuming you are in a bash window (whether on 
> cygwin or ubuntu 18, or mac os) and you do this:
>
>   > ./myScript.py
>
> How do you write the shebang so it runs reliably python3 with the minimal 
> amount of energy spent configuring the system.

If you're in a bash window on Cygwin, did you install Cygwin Python or
Windows native Python? The answer is probably different depending on
which scenario applies. And integrating Cygwin bash with native
Windows Python is always going to be a little clumsy, as you're
dealing with the differences with two environments that work very
differently.

Paul
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HZKUJAQH7DJM5JUDZVBKH4WFJLNSAYBE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Eric V. Smith]

On 3/24/2020 6:58 AM, Frédéric De Jaeger wrote:


One of our constraint is that we use Cygwin's bash and now, every user relies 
on the shebang.
The problem reduce to this.  Assuming you are in a bash window (whether on 
cygwin or ubuntu 18, or mac os) and you do this:

   > ./myScript.py

How do you write the shebang so it runs reliably python3 with the minimal 
amount of energy spent configuring the system.


Why don't you just install the cygwin version of python3? That will put 
python3 in your path, and I think solve your problem. That's the setup I 
use.


Cygwin should make it easier to have Windows look like Unix, not harder.

Eric
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/CZ4YPLBK2BZOK2ZQ3YIDSFIIZZVLEVV2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Oleg Broytman]

On Tue, Mar 24, 2020 at 10:21:33AM +, Barry Scott  
wrote:
> > On 23 Mar 2020, at 17:59, Fr??d??ric De Jaeger  
> > wrote:
> > The issue is:  There is no reliable way to launch a python script.  
> > 
> > The command:
> > 
> > python myscript.py
> > 
> > launches python3 on windows and python2 on 99% of the unix market.
> > 
> > The command
> > 
> >   python3 myscript.py
> 
> The windows version would be
> 
> py myscript.py

   That is, **in addition** to ``python`` and ``python3`` Fred should
learn, use and teach ``py``?

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/KJSXUHWY7RUUZB46F7LVRTNROHIA3HMK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Oleg Broytman]

On Tue, Mar 24, 2020 at 09:40:07AM +, Rhodri James  
wrote:
> I'm afraid the terseness of your answer didn't make it at all clear how
> creating venvs would solve Fred's problems.  It still isn't obvious to me!

One doesn't create virtual environments every day; once a year may be.
And there are projects that help managing environments if there are many
(virtualenvwrapper and virtualenvwrapper-win).

One doesn't activate venvs to run every script; once a day usually, or
once for every new terminal. And there're projects that help running
scripts in venvs automatically (pipsi and pipx).

Once a venv is activated there is no need to remember different commands
-- it's always ``python`` and ``pip``. In all operating systems. It's
what the OP wants, right?

> -- 
> Rhodri James *-* Kynesim Ltd

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/K4ZBR6NR3FLUV2ZQKBQTXQLUUMSCAUXH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Frédéric De Jaeger]

> Windows devices, they might want to consider using the PrependPath option
> (which adds Python to PATH from the command line). I.E.
> python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1
> (IIRC, the above installation should allow usage of "python3" on
> Windows for all users on the device)

That would be nice.  Does it apply to the _windows store version_,  the 
_traditional installer_, both ?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/WQFJ4YGNUCKBITTHZQCME3GQRXPVPYT2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Frédéric De Jaeger]

Steven D'Aprano wrote:
> On Mon, Mar 23, 2020 at 05:59:41PM -, Frédéric De Jaeger wrote:
> > The issue is:  There is no reliable way to launch a
> > python script.
> > The command:
> >  python myscript.py
> > 
> > launches python3 on windows and python2 on 99% of the unix market.
> > Its probably less than 99% by now, but still quite high.
> Do I understand you that "python" (without a full pathname) is supported 
> on Windows? If I understand Brett's later comment, I expect that by 
> default your Windows users will need to type the full pathname, since 
> Python isn't added to the PATH.

I suppose we tell all our windows users (which I'm not) to be sure to have 
python in their PATH.  So they should have used the installer facility for that.


> Are you familar with the py.exe Windows launcher? Does it help?
> https://www.python.org/dev/peps/pep-0397/
> Perhaps you can just have your Windows users call "py myscript.py" and 
> your non-Windows users call "myscript.py" (after setting the 
> appropriate hashbang referring to python3).

One of our constraint is that we use Cygwin's bash and now, every user relies 
on the shebang.
The problem reduce to this.  Assuming you are in a bash window (whether on 
cygwin or ubuntu 18, or mac os) and you do this:

  > ./myScript.py

How do you write the shebang so it runs reliably python3 with the minimal 
amount of energy spent configuring the system.

So, `py` launcher does not seem to solve our problem.


> In other words, your idea is for Python on Windows to support "python3" 
> as well as "python". Is that correct?

Yes, that would be ideal.  All our scripts would work out of the box, given our 
workflow.

From that doc:  
https://docs.python.org/3/using/windows.html#the-microsoft-store-package

It seems `python3.exe` is available when we installed python from the windows 
store.  So maybe a solution is that we tell our employees to install that
version instead.

That is just a bit odd the _traditional installer_ does not do the same thing.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/5V4AJGK3HFKM7XGCLZUA75K2OTAJN5QO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Barry Scott]

> On 23 Mar 2020, at 17:59, Frédéric De Jaeger  wrote:
> 
> Hi all,
> 
> There is a recurring problem in my company where we use python in various 
> places (python3). 
> We do cross platform development windows/linux and our python scripts need to 
> run everywhere.
> Some scripts are launched manually in a terminal. 
> Others are launched via windows' gui interface.  
> Others are launched through our build process (cmake based, but also manual 
> Makefile)
> And others are launched via bash scripts.
> And possible several other scenario I've forgot.
> 
> On windows, most users use Cygwin to do their terminal based business (`git`, 
> `cmake`, ...).
> 
> The issue is:  There is no reliable way to launch a python script.  
> 
> The command:
> 
> python myscript.py
> 
> launches python3 on windows and python2 on 99% of the unix market.
> 
> The command
> 
>   python3 myscript.py

The windows version would be

py myscript.py

If you have python 2 and 3 installed then

   py -3 myscript

py.exe can run any installed version of python and if only one is installed 
that it will default to the one of only.

re: use venv

Do not see the need to add venv complexity to the mix just to start an 
installed python.

The py.exe can run any installed version of python. I use that all the time 
when testing against
multiple versions.

py -2.7-32 myscript.py
py -2.7-64 mysctipt.py
...
py -3.7-64 myscript.py

> 
> does not run on windows with the latest python distribution I've played with 
> (sorry if it has been fixed recently, this whole mail becomes pointless).
> 
> Human can learn which command to run, it's ok.  But for all other invocations 
> context, this becomes very annoying.

Switching between linux and Windows requires all sorts of different UI to be 
aware of.
How to get a terminal prompt, how to get a directory listing, etc.

>  Surprisingly, `cmake` is the more friendly, since `FindPython` will returns 
> a python3 first.
> 
> At the moment, we have scripts that run under version 2 when run by a linux 
> user and version 3 on windows.  This works by pure luck.
> 
> If the standard python distro would just provide a simple `python3` 
> binary/alias, then all the stars would align perfectly.  
> the basic shebang
> 
> #! /usr/bin/env python3

This does work out of the box because py.exe is run when you execute a .py in 
the CMD.

C:\>   my-py3-script.py

Note: Installing python2 seems to prevent py.exe getting setup for .py files.

You can check by doing:

assoc .py
ftype Python.File

If Python.File is not using py.exe then you can fix that with this command from 
an Admin CMD.

ftype Python.File="C:\windows\py.exe" "%1" %*

Barry

> 
> would work everywhere by default, without requiring any tweaking (install a 
> python3 alias on windows, or ask linux users to change the default `python` 
> symlink)
> 
> I'm sure, I'm far from being the first user complaining about that.  Sorry if 
> the request has been been made numerous time before. 
> 
> What it the status on this point ?  
> 
> Thanks a lot.
> 
> Fred
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-ideas@python.org/message/PTYLAO7YXM4UH3CEI3BRBRALM3AL4HJQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
> 
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RGNMOOH7GVHIUUDEYFFOT6DNHXYWDT2Z/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Rhodri James]

On 24/03/2020 01:13, Oleg Broytman wrote:

On Tue, Mar 24, 2020 at 11:30:38AM +1100, Steven D'Aprano  
wrote:

Fred is explicitly asking about the problem with having to sometimes use
python and sometimes python3, and your answer is to tell him to
sometimes use python and sometimes use python3?


Once for every venv created, not once for every script being run.


I'm afraid the terseness of your answer didn't make it at all clear how 
creating venvs would solve Fred's problems.  It still isn't obvious to me!



Fred is discussing the problems he is having with distribution and
deployment, not development.


IMO the issue is in not following the best practices. Distribute wheels
or freezed binaries, not just drop scripts unto users.


For most circumstances, that is not a practical answer.  Creating wheels 
or frozen binaries are subjects that most Python programmers know little 
about and care less about.  Expecting someone to learn how to wield the 
packaging system just to do internal distribution is unrealistic.


Also, where is it said that distributing wheels or frozen binaries is 
best practice?  I wasn't aware of any such statement, and indeed have 
seen frozen binaries discouraged in the past.


--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/BCNNWCBU4VXGDEDU3HL5QGOAUHX5XRP4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Oleg Broytman]

On Tue, Mar 24, 2020 at 11:30:38AM +1100, Steven D'Aprano  
wrote:
> On Tue, Mar 24, 2020 at 12:45:42AM +0100, Oleg Broytman wrote:
> 
> > > Won't that create a virtual environment using Python3 on Windows and 
> > > using Python2 most other places, which is exactly the problem Fred is 
> > > having?
> > 
> > Depends on how literally one reads ``python -m venv``.
> 
> I read it as what you wrote, should I have read it as something else?

As a template.

> Fred is explicitly asking about the problem with having to sometimes use 
> python and sometimes python3, and your answer is to tell him to 
> sometimes use python and sometimes use python3?

Once for every venv created, not once for every script being run.

> > Python virtualenv is a development tool but not a distribution or
> > a deployment tool.
> 
> Fred is discussing the problems he is having with distribution and 
> deployment, not development.

IMO the issue is in not following the best practices. Distribute wheels
or freezed binaries, not just drop scripts unto users.

> His issue is that "python" means different 
> things on different machines and different users.

This part is not solvable. Python **means** different things on
different machines and different users.

> -- 
> Steven

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/VMZBOM6SOWX3LPSKQAXMP5FUE45QSWYH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Steven D'Aprano]

On Mon, Mar 23, 2020 at 05:59:41PM -, Frédéric De Jaeger wrote:

> The issue is:  There is no reliable way to launch a python script.  
> 
> The command:
> 
>  python myscript.py
> 
> launches python3 on windows and python2 on 99% of the unix market.

Its probably less than 99% by now, but still quite high.

Do I understand you that "python" (without a full pathname) is supported 
on Windows? If I understand Brett's later comment, I expect that by 
default your Windows users will need to type the full pathname, since 
Python isn't added to the PATH.

Are you familar with the py.exe Windows launcher? Does it help?

https://www.python.org/dev/peps/pep-0397/

Perhaps you can just have your Windows users call "py myscript.py" and 
your non-Windows users call "myscript.py" (after setting the 
appropriate hashbang referring to python3).


> At the moment, we have scripts that run under version 2 when run by a 
> linux user and version 3 on windows.  This works by pure luck.

If I have understood your problem correctly, I think the smallest, least 
invasive change to have this all "just work" is:

- have all your scripts specify "python3" in their hashbang 
  rather than "python";

- add a "python3 --> python" alias on Windows.


Which I think is what you are asking here:

> If the standard python distro would just provide a simple `python3` 
> binary/alias, then all the stars would align perfectly.  the basic 
> shebang
> 
>  #! /usr/bin/env python3
> 
> would work everywhere by default, without requiring any tweaking 
> (install a python3 alias on windows, or ask linux users to change the 
> default `python` symlink)

In other words, your idea is for Python on Windows to support "python3" 
as well as "python". Is that correct?

I'm not a Windows user, so I don't know if there is a downside to that 
idea, but if your analysis is correct is seems like a good, simple idea.



-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/QIUTZHFP2BIF6YPRWKE6EVJ67FKI7AKG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Steven D'Aprano]

On Tue, Mar 24, 2020 at 12:45:42AM +0100, Oleg Broytman wrote:

> > Won't that create a virtual environment using Python3 on Windows and 
> > using Python2 most other places, which is exactly the problem Fred is 
> > having?
> 
> Depends on how literally one reads ``python -m venv``.

I read it as what you wrote, should I have read it as something else?

Fred is explicitly asking about the problem with having to sometimes use 
python and sometimes python3, and your answer is to tell him to 
sometimes use python and sometimes use python3?


> Python virtualenv is a development tool but not a distribution or
> a deployment tool.

Fred is discussing the problems he is having with distribution and 
deployment, not development. His issue is that "python" means different 
things on different machines and different users.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/IQSYMD2J5KTHV4T22S7XAYCU4EBKANGZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Kyle Stanley]

Brett Cannon wrote:
> There is an option to install Python to PATH on Windows if you check the
appropriate box during installation, but that's not really the
> way Windows apps typically work.

In this case of the OP, if they're mass installing Python on company
Windows devices, they might want to consider using the PrependPath option
(which adds Python to PATH from the command line). I.E.

python-3.8.0.exe /quiet InstallAllUsers=1 PrependPath=1

(IIRC, the above installation should allow usage of "python3" on
Windows for all users on the device)


On Mon, Mar 23, 2020 at 7:52 PM Brett Cannon  wrote:

>
>
> On Mon, Mar 23, 2020 at 3:47 PM Mike Miller 
> wrote:
>
>>
>> On 2020-03-23 10:59, Frédéric De Jaeger wrote:
>> > Hi all,
>> >
>> > There is a recurring problem
>>
>> Yep, that's a problem.  I've built up a habit on Ubuntu where I type
>> python3 a
>> number of times a day, honed over several years.  So far so good.
>>
>
> Also note that Python doesn't control the OS vendors and this is very much
> a vendor decision. We tried to provide guidance, but that doesn't mean we
> are listened to. :)
>
>
>>
>> Recently I've had to use a Windows VM for some stuff at work, where I
>> installed
>> Python 3 as well.  Every time I type python3 at the command-line (instead
>> of
>> python) to use the repl, it tries to load the Microsoft App Store!
>>
>
> There is an option to install Python to PATH on Windows if you check the
> appropriate box during installation, but that's not really the way Windows
> apps typically work.
>
>
>>
>> I realize why that was done, to help out newbies, but it is not what I
>> want at
>> all.  Not the end of the world, but some consistency would be nice.
>>
>
> As I said, you can install Python to PATH on Windows if you choose.
>
> I'm also slowly working on a Python Launcher for UNIX so the other option
> some day might be `py` no matter what OS you're on.
>
> -Brett
>
>
>>
>> -Mike
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/4XXUECWBIFLK6IRW7FA6TXLUIYQ7CQHS/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/NZ3J3Y6GEQDBU7U2ID4L5J4CHRG4LWHS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/RR5MWZD6DB6KAY2FSSY5CIMH5PQYB2UL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Brett Cannon]

On Mon, Mar 23, 2020 at 3:47 PM Mike Miller 
wrote:

>
> On 2020-03-23 10:59, Frédéric De Jaeger wrote:
> > Hi all,
> >
> > There is a recurring problem
>
> Yep, that's a problem.  I've built up a habit on Ubuntu where I type
> python3 a
> number of times a day, honed over several years.  So far so good.
>

Also note that Python doesn't control the OS vendors and this is very much
a vendor decision. We tried to provide guidance, but that doesn't mean we
are listened to. :)


>
> Recently I've had to use a Windows VM for some stuff at work, where I
> installed
> Python 3 as well.  Every time I type python3 at the command-line (instead
> of
> python) to use the repl, it tries to load the Microsoft App Store!
>

There is an option to install Python to PATH on Windows if you check the
appropriate box during installation, but that's not really the way Windows
apps typically work.


>
> I realize why that was done, to help out newbies, but it is not what I
> want at
> all.  Not the end of the world, but some consistency would be nice.
>

As I said, you can install Python to PATH on Windows if you choose.

I'm also slowly working on a Python Launcher for UNIX so the other option
some day might be `py` no matter what OS you're on.

-Brett


>
> -Mike
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/4XXUECWBIFLK6IRW7FA6TXLUIYQ7CQHS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NZ3J3Y6GEQDBU7U2ID4L5J4CHRG4LWHS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Oleg Broytman]

On Tue, Mar 24, 2020 at 10:22:28AM +1100, Steven D'Aprano  
wrote:
> On Mon, Mar 23, 2020 at 08:09:57PM +0100, Oleg Broytman wrote:
> > On Mon, Mar 23, 2020 at 05:59:41PM -, Fr??d??ric De Jaeger 
> >  wrote:
> > > The issue is:  There is no reliable way to launch a python script.
> > > 
> > > The command:
> > > 
> > >  python myscript.py
> > > 
> > > launches python3 on windows and python2 on 99% of the unix market.
> > 
> > Create and activate a virtual environment (``virtualenv`` or
> > ``python -m venv``) and always use ``python myscript.py``.
> 
> Won't that create a virtual environment using Python3 on Windows and 
> using Python2 most other places, which is exactly the problem Fred is 
> having?

Depends on how literally one reads ``python -m venv``. Just for example:
I run a lot of tests for my libraries locally under all possible Pythons
so I have all versions -- 2.7 and 3.4+ up to 3.8 (soon to add 3.9) -- so
I create all possible venvs; I run Windows inside VirtualBox emulator
where I have even more Pythons -- 32-bit and 64-bit.

When I need a particular version I create, activate and populate a
specific venv.

> Doesn't using a virtual environment require the caller to explicitly 
> activate it, otherwise they will still get the system (global) Python? 

Yes. I don't think it's a major problem. Activating a venv once (for a
terminal) is surely simpler than remembering the difference between
``python`` and ``python3``, ``pip`` and ``pip3``, ``pip2.7``, ``pip3.5``
and ``pip3.6``.

> If Fred successfully creates a virtualenv using the correct version of 
> Python, how does that help him when he distributes his script across his 
> organisation, and to his users? Some of them may not have access to 
> Fred's virtualenv.

Python virtualenv is a development tool but not a distribution or
a deployment tool. To distribute a script one is recommended to build a
wheel and allow ``pip`` to configure the script to use a proper Python
version.

Even better (but harder) distribution/deployment tools are freezers --
cx_Freeze/PyInstaller/pyapp/pyexe. They bundle the required Python and a
subset of the standard library with the script.

Even better (but even more harder) are OS-specific installers --
RPM, deb, w32 installers.

> These are not rhetorical questions. I'm not a heavy virtualenv user and 
> I may not understand it fully.
> -- 
> Steven

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/HO45ZXZ6XHPZNDC2I3QRCUVGKTP5ME66/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Steven D'Aprano]

On Mon, Mar 23, 2020 at 08:09:57PM +0100, Oleg Broytman wrote:
> On Mon, Mar 23, 2020 at 05:59:41PM -, Fr??d??ric De Jaeger 
>  wrote:
> > The issue is:  There is no reliable way to launch a python script.
> > 
> > The command:
> > 
> >  python myscript.py
> > 
> > launches python3 on windows and python2 on 99% of the unix market.
> 
> Create and activate a virtual environment (``virtualenv`` or
> ``python -m venv``) and always use ``python myscript.py``.

Won't that create a virtual environment using Python3 on Windows and 
using Python2 most other places, which is exactly the problem Fred is 
having?

Doesn't using a virtual environment require the caller to explicitly 
activate it, otherwise they will still get the system (global) Python? 

If Fred successfully creates a virtualenv using the correct version of 
Python, how does that help him when he distributes his script across his 
organisation, and to his users? Some of them may not have access to 
Fred's virtualenv.

These are not rhetorical questions. I'm not a heavy virtualenv user and 
I may not understand it fully.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/NSOQTI6EIYXSUUUKLLR7UT5JG7FVTN5F/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Mike Miller]

On 2020-03-23 10:59, Frédéric De Jaeger wrote:

Hi all,

There is a recurring problem


Yep, that's a problem.  I've built up a habit on Ubuntu where I type python3 a 
number of times a day, honed over several years.  So far so good.


Recently I've had to use a Windows VM for some stuff at work, where I installed 
Python 3 as well.  Every time I type python3 at the command-line (instead of 
python) to use the repl, it tries to load the Microsoft App Store!


I realize why that was done, to help out newbies, but it is not what I want at 
all.  Not the end of the world, but some consistency would be nice.


-Mike
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/4XXUECWBIFLK6IRW7FA6TXLUIYQ7CQHS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Oleg Broytman]

On Mon, Mar 23, 2020 at 05:59:41PM -, Fr??d??ric De Jaeger 
 wrote:
> The issue is:  There is no reliable way to launch a python script.
> 
> The command:
> 
>  python myscript.py
> 
> launches python3 on windows and python2 on 99% of the unix market.

Create and activate a virtual environment (``virtualenv`` or
``python -m venv``) and always use ``python myscript.py``.

Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PIF65YSJPF5RECKWYGPT7YFQTYK33NBE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Andrew Barnert via Python-ideas]

> On Mar 23, 2020, at 11:16, Frédéric De Jaeger  wrote:
> 
> The command:
> 
>python myscript.py
> 
> launches python3 on windows and python2 on 99% of the unix market.

While that’s true for Mac 10.14, Ubuntu 18.04 LTS, etc., I think almost 
everyone is deprecating Python 2 in their current releases, so that’s not 
really true anymore. And, while there’s nothing wrong with running 2-year-old 
OS versions, I’m not sure it’s worth making any changes to Python to help such 
environments, because it won’t help many people until after it’s too late to 
matter anyway. (If Python 3.10 does something different, and it becomes the 
default in Ubuntu 22.04 LTS, your company probably won’t see any benefit until 
at least 2023…)

It’s worth reading PEP 394 (the Python command on Unix-like systems) and PEP 
397 (the Python launcher for Windows) for background. But I think the 
assumption is that you create executable scripts with #! /usr/bin/env python3, 
and then your other scripts just execute the scripts directly, which will go 
through the default shell on *nix (which will process the shbang line and run 
whatever is called python3 on the path) and through py.exe on Windows (which 
has special code to understand common shbang lines and do the right thing).

But there are other options to make things even easier.

If you use virtual environments, the python command inside a venv always runs 
the Python version for that venv.

If you create things to be installed rather than run in-place, setuptools entry 
points automatically get turned into scripts set up in a way that’s appropriate 
for the local system.

If you have Windows users who aren’t Python-savvy at all, it may even be worth 
using one of the binary-program makers like PyInstaller so they can just run an 
installer off your intranet and get something that looks like a normal .exe 
file on their PATH that doesn’t depend on any Python installation.

One more thing:

> On windows, most users use Cygwin to do their terminal based business (`git`, 
> `cmake`, ...).

It’s been a while since I worked in a Cygwin-heavy environment, but if you’re 
writing shell scripts to run in Cygwin that use Python scripts, don’t you still 
need a Cygwin Python rather than a native Windows ones, so things like 
pathnames work properly? Or is that not a problem anymore? And if you do, 
doesn’t the Cygwin Python 3 package install something named python3 that’s on 
the (Cygwin) PATH, same as on your *nix systems?

___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/6HVWI3AHDBNOWE3X3CQQBGXRQMQNGUIG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: About python3 on windows

[Steve Barnes]

Hi Fred,

If windows users associate .py with the py.exe launcher, (and .pyw with the 
pyw.exe launcher), then it will default to python 3 (highest version installed, 
64 bit if available), and will honour a `#! python3` shebang, (with a number of 
formats accepted). It should also be reasonably easy to teach the users to 
type: py scriptname rather than python or python3 scriptname (less to type 
rather than more).

The link for details is 
https://docs.python.org/3/using/windows.html#python-launcher-for-windows and 
there are details on installation further up the page.

Hope that this answers your problem.

Steve Barnes


-Original Message-
From: Frédéric De Jaeger  
Sent: 23 March 2020 18:00
To: python-ideas@python.org
Subject: [Python-ideas] About python3 on windows

Hi all,

There is a recurring problem in my company where we use python in various 
places (python3). 
We do cross platform development windows/linux and our python scripts need to 
run everywhere.
Some scripts are launched manually in a terminal. 
Others are launched via windows' gui interface.  
Others are launched through our build process (cmake based, but also manual 
Makefile) And others are launched via bash scripts.
And possible several other scenario I've forgot.

On windows, most users use Cygwin to do their terminal based business (`git`, 
`cmake`, ...).

The issue is:  There is no reliable way to launch a python script.  

The command:

 python myscript.py

launches python3 on windows and python2 on 99% of the unix market.

The command

   python3 myscript.py

does not run on windows with the latest python distribution I've played with 
(sorry if it has been fixed recently, this whole mail becomes pointless).

Human can learn which command to run, it's ok.  But for all other invocations 
context, this becomes very annoying.  Surprisingly, `cmake` is the more 
friendly, since `FindPython` will returns a python3 first.

At the moment, we have scripts that run under version 2 when run by a linux 
user and version 3 on windows.  This works by pure luck.

If the standard python distro would just provide a simple `python3` 
binary/alias, then all the stars would align perfectly.  
the basic shebang

 #! /usr/bin/env python3

would work everywhere by default, without requiring any tweaking (install a 
python3 alias on windows, or ask linux users to change the default `python` 
symlink)

I'm sure, I'm far from being the first user complaining about that.  Sorry if 
the request has been been made numerous time before. 

What it the status on this point ?  

Thanks a lot.

Fred
___
Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an 
email to python-ideas-le...@python.org 
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/PTYLAO7YXM4UH3CEI3BRBRALM3AL4HJQ/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/YAGPL3NO7J4MQYGGFT6R2JWFYESWIFJJ/
Code of Conduct: http://python.org/psf/codeofconduct/