[Python-ideas] Re: New explicit methods to trim strings

[Christopher Barker]

On Mon, Mar 23, 2020 at 6:01 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

>  > This is now a draft PEP, and being (has been?) discussed on python-dev
> --
>  > time to go there is you want more input.
>
> They don't, and it's a "idea" separate from the PEP.


Sure, then please starter a new thread, or at least change the title.

-CHB

-- 
Christopher Barker, PhD

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/HTGY72XY6AN3ULNLAWHEXH3XXSOCRHO6/
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: Instance method to test equivalence between set and iterable

[Steve Jorgensen]

Steven D'Aprano wrote:
> On Mon, Mar 23, 2020 at 12:03:50AM -, Steve Jorgensen wrote:
> > Every set is a superset of itself and a subset of
> > itself. A set may 
> > not be a "formal" subset or a "formal" superset of itself. issubset 
> > and issuperset refer to standard subsets and supersets, not formal 
> > subsets and supersets.
> > Sorry, I don't understand your terminology "formal" and "standard". I 
> think you might mean "proper" rather than formal? But I don't know what 
> you mean by "standard".
 

Right. I meant "proper". Not "formal". By "standard", I simply mean without the 
"proper" qualifier.
___
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/GGAKYH5HFZHIPTOIXJA64MY2W7BAIZMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[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. 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
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/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: Instance method to test equivalence between set and iterable

[Rob Cliffe via Python-ideas]

On 23/03/2020 23:49, Steven D'Aprano wrote:

On Mon, Mar 23, 2020 at 02:05:49PM +, Rob Cliffe via Python-ideas wrote:


s = set("a")
t = list("aa")
s.issubset(t)

True

s.issuperset(t)

True

but it would be misleading IMO to say that s and t are in some sense
equal.

In *some* sense they are equal:

- every element in s is also in t;
- every element in t is also in s;
- no element in s is not in t;
- no element in t is not in s;
- modulo uniqueness, both s and t have the same elements;
- converting t to a set gives {'a'} which is equal to s.

I don't know that this is an *important* sense, but the OP Steve J isn't
wrong to notice it.

I shouldn't need to say this, but for the record I am not proposing and
do not want set equality to support lists; nor do I see the need for a
new method to perform "equivalent to equality" tests; but if the
consensus is that sets should have that method, I would prefer it to be
given the simpler name:

 set.superset  # not .equivalent_to_superset
 set.subset# not .equivalent_to_subset
 set.equals# not some variation of .equivalent_to_equals


I could have expressed myself more clearly.  What I mean is that if the 
new method accepts an arbitrary iterable,
it should not have a name such as 'equals' or 'isequal' because that is 
just plain misleading - it should be called something

less definite like 'iscoextensive' or [your suggestion here].
Conversely, if the new method only accepts a set as argument, it's fine 
to call it 'isequal' or whatever, because when

it returns True the two sets *will* be equal.
Rob Cliffe
___
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/VQ3ZK3TYV4FUDPPIW4NKG4YBAZ7XMFJM/
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: Instance method to test equivalence between set and iterable

[M.-A. Lemburg]

Hi Steven,

I think you are taking this a bit too far out of what we normal use
Python for in real life :-)

The mathematical complication of not having

∀x(x∈S ↔ x∈T) → S = T

be a consequence of

S = T → (∀x)(x∈S ↔ x∈T)

which may sound weird to many people, originates in the fact that the
above must also hold for infinite number of elements in a set, including
uncountably infinite sets and sets which have such sets as elements
(including possibly uncountably infinite recursion of such inclusions).
You enter a world full of wonders when you start considering such things.

In Python, however, we typically always operate on finite sets. In such
a world, the above is not a complication anymore. In fact, the C
implementation uses:

|S| = |T| ∧ S ⊆ T → S = T

or written using the above form:

|S| = |T| ∧ ∀x(x∈S → x∈T)→ S = T


Cheers.


On 3/24/2020 11:19 AM, Steven D'Aprano wrote:
> Apologies in advance... the following is going to contain mathematical 
> jargon and pedantry. Run now while you still can *wink*
>
>
> On Tue, Mar 24, 2020 at 12:56:55AM -0700, Andrew Barnert wrote:
> On Mar 23, 2020, at 19:52, Steven D'Aprano  wrote:
 On Mon, Mar 23, 2020 at 06:03:06PM -0700, Andrew Barnert wrote:
 The existing methods are named issubset and issuperset (and
 isdisjoint, which doesn’t have an operator near-equivalent). Given
 that, would you still want equals instead of isequal or something?
>>> Oops! I mean, aha, you passed my test to see if you were paying 
>>> attention, well done!
>>>
>>> *wink*
>>>
>>> I would be satisfied by "isequal", if the method were needed.
>>>
>>>
 So, I’d rather have an uglier, more explicit, and more obviously
 specific-to-set name like iscoextensive. Sure, not everyone will know
 what “coextensive” means
>>> That's an unnecessary use of jargon
>> As far as I’m aware (and your MathWorld search bears this out), 
>> “coextensive” isn’t mathematical jargon.
> No, it's definitely mathematical jargon, but *really* specialised. As 
> far as I can tell, it's only used by people working on the foundations 
> of logic and set theory. I haven't come across it elsewhere.
>
> For example:
>
> https://books.google.com.au/books?id=wEa9DwAAQBAJ=PA284=PA284=math+coextensive+set+difference+with+equality=bl=y-jmrSTxC8=ACfU3U18oCjeXSfwwqML1zuVWwbSJdeZ2Q=en=X=2ahUKEwjqzfGBhbLoAhUOzDgGHfqSAbIQ6AEwAHoECAkQAQ#v=onepage=math%20coextensive%20set%20difference%20with%20equality=false
>
> "Introduction To Discrete Mathematics Via Logic And Proof" by Calvin 
> Jongsma, on pages 283-4, it says:
>
> First-Order Logic already has a fixed, standard notation of 
> identity governed by rules of inference. S = T logically implies
> (∀x)(x∈S ↔ x∈T) [...] Thus identical sets must contain exactly
> the same elements. However we can't turn this claim around and 
> say that sets having the same elements are identical -- 
> *set equality for coextensive sets doesn't follow from logic alone.*
> We'll therefore postulate this as an axiom, using the formal 
> notation of FOL.
>
> Axiom 5.3.1: Axiom of Extensionality
> ∀x(x∈S ↔ x∈T) → S = T
>
> The crierion for equal sets (see Definition 4.1.1 follows 
> immediately:
>
> Proposition 5.3.1: Equal Sets
> S = T ↔ ∀x(x∈S ↔ x∈T)
>
>
> Apologies to everyone who got lost reading that :-)
>
> In the above quote, "identity" should be read as "equality". The 
> emphasised clause "set equality for coextensive sets..." is in the 
> original. The upside down A ∀ means "for all", the rounded E ∈ means 
> "element of".
>
> So translated into English, what the author is saying is that he has a 
> concept of two sets being equal, S = T. He has another concept of two 
> sets being coextensive, namely, that for each element in S, it is also 
> in T, and vice versa. He then says that if two sets are identical 
> (equal), then logically they must also be coextensive, but to go the 
> other way (coextensive implies equality) we have to make it part of the 
> definition.
>
> That's a long-winded, pedantic and precise way of saying that two sets 
> are equal if, and only if, they have precisely the same elements as each 
> other, by definition.
>
>
>> I chose it because of its ordinary (if not super-common) English 
>> meaning.
> Oh.
>
> Well, you outsmarted me, or perhaps outdumbed me *smiles* because it 
> definitely is a term from mathematics, whether you knew it or not.
>
> I thought that you were referring to the mathematical usage.
>
> As far as the non-mathematical meaning:
>
> being of equal extent or scope or duration;
> having the same spatial limits or boundaries;
>
> I think we would be justified as reading `A.iscoextensive(B)` in one of 
> two ways:
>
> len(A) == len(B)
> (min(A), max(A)) == (min(B), max(B))
>
> but not necessarily as equal.
>
> Why not equal? Consider somebody who started a project on the day of the 
> Olypics Opening Ceremony, and finished the project on the day of 

[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: Instance method to test equivalence between set and iterable

[Steven D'Aprano]

Apologies in advance... the following is going to contain mathematical 
jargon and pedantry. Run now while you still can *wink*


On Tue, Mar 24, 2020 at 12:56:55AM -0700, Andrew Barnert wrote:
> >>> On Mar 23, 2020, at 19:52, Steven D'Aprano  wrote:
> >> On Mon, Mar 23, 2020 at 06:03:06PM -0700, Andrew Barnert wrote:
> >> The existing methods are named issubset and issuperset (and
> >> isdisjoint, which doesn’t have an operator near-equivalent). Given
> >> that, would you still want equals instead of isequal or something?
> > 
> > Oops! I mean, aha, you passed my test to see if you were paying 
> > attention, well done!
> > 
> > *wink*
> > 
> > I would be satisfied by "isequal", if the method were needed.
> > 
> > 
> >> So, I’d rather have an uglier, more explicit, and more obviously
> >> specific-to-set name like iscoextensive. Sure, not everyone will know
> >> what “coextensive” means
> > 
> > That's an unnecessary use of jargon
> 
> As far as I’m aware (and your MathWorld search bears this out), 
> “coextensive” isn’t mathematical jargon.

No, it's definitely mathematical jargon, but *really* specialised. As 
far as I can tell, it's only used by people working on the foundations 
of logic and set theory. I haven't come across it elsewhere.

For example:

https://books.google.com.au/books?id=wEa9DwAAQBAJ=PA284=PA284=math+coextensive+set+difference+with+equality=bl=y-jmrSTxC8=ACfU3U18oCjeXSfwwqML1zuVWwbSJdeZ2Q=en=X=2ahUKEwjqzfGBhbLoAhUOzDgGHfqSAbIQ6AEwAHoECAkQAQ#v=onepage=math%20coextensive%20set%20difference%20with%20equality=false

"Introduction To Discrete Mathematics Via Logic And Proof" by Calvin 
Jongsma, on pages 283-4, it says:

First-Order Logic already has a fixed, standard notation of 
identity governed by rules of inference. S = T logically implies
(∀x)(x∈S ↔ x∈T) [...] Thus identical sets must contain exactly
the same elements. However we can't turn this claim around and 
say that sets having the same elements are identical -- 
*set equality for coextensive sets doesn't follow from logic alone.*
We'll therefore postulate this as an axiom, using the formal 
notation of FOL.

Axiom 5.3.1: Axiom of Extensionality
∀x(x∈S ↔ x∈T) → S = T

The crierion for equal sets (see Definition 4.1.1 follows 
immediately:

Proposition 5.3.1: Equal Sets
S = T ↔ ∀x(x∈S ↔ x∈T)


Apologies to everyone who got lost reading that :-)

In the above quote, "identity" should be read as "equality". The 
emphasised clause "set equality for coextensive sets..." is in the 
original. The upside down A ∀ means "for all", the rounded E ∈ means 
"element of".

So translated into English, what the author is saying is that he has a 
concept of two sets being equal, S = T. He has another concept of two 
sets being coextensive, namely, that for each element in S, it is also 
in T, and vice versa. He then says that if two sets are identical 
(equal), then logically they must also be coextensive, but to go the 
other way (coextensive implies equality) we have to make it part of the 
definition.

That's a long-winded, pedantic and precise way of saying that two sets 
are equal if, and only if, they have precisely the same elements as each 
other, by definition.


> I chose it because of its ordinary (if not super-common) English 
> meaning.

Oh.

Well, you outsmarted me, or perhaps outdumbed me *smiles* because it 
definitely is a term from mathematics, whether you knew it or not.

I thought that you were referring to the mathematical usage.

As far as the non-mathematical meaning:

being of equal extent or scope or duration;
having the same spatial limits or boundaries;

I think we would be justified as reading `A.iscoextensive(B)` in one of 
two ways:

len(A) == len(B)
(min(A), max(A)) == (min(B), max(B))

but not necessarily as equal.

Why not equal? Consider somebody who started a project on the day of the 
Olypics Opening Ceremony, and finished the project on the day of the 
Closing Ceremony. We can say that the project and the Olympics were 
coextensive, but we can't necessarily say that they were equal or the 
same thing, or that the project was the Olympics.


[...]
> Sure, but in math, just as in Python, a set is never equal to a list 
> (with a tiny foundations asterisk that isn’t relevant, but I’ll 
> mention it below).

Well, yes and no.

In Python, just as in mathematics, a set is never a superset or subset 
of a list either, and yet in Python we have a set method which quite 
happily says that a set can be a superset or subset (or equal to) a 
list:

{1, 2}.issubset([2, 1])  # Returns True

We understand that, unlike the operators `<` and `<=`, the issubset 
method is happy to (conceptually) coerce the list into a set.


> So when mathematicians want to say a set is equal to a list… well, 
> they just don’t say that, because it isn’t true, and usually isn’t 
> even a meaningful question in the first place.

Don't you think that there is a sense 

[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: Instance method to test equivalence between set and iterable

[Andrew Barnert via Python-ideas]

>>> On Mar 23, 2020, at 19:52, Steven D'Aprano  wrote:
>> On Mon, Mar 23, 2020 at 06:03:06PM -0700, Andrew Barnert wrote:
>> The existing methods are named issubset and issuperset (and
>> isdisjoint, which doesn’t have an operator near-equivalent). Given
>> that, would you still want equals instead of isequal or something?
> 
> Oops! I mean, aha, you passed my test to see if you were paying 
> attention, well done!
> 
> *wink*
> 
> I would be satisfied by "isequal", if the method were needed.
> 
> 
>> So, I’d rather have an uglier, more explicit, and more obviously
>> specific-to-set name like iscoextensive. Sure, not everyone will know
>> what “coextensive” means
> 
> That's an unnecessary use of jargon

As far as I’m aware (and your MathWorld search bears this out), “coextensive” 
isn’t mathematical jargon. I chose it because of its ordinary (if not 
super-common) English meaning. For example, the charter of the City of San 
Francisco says that the city is coextensive with the County of San Francisco, 
meaning that any bit of land in the city is in the county and vice-versa. I’m 
sure it’s not the only word that’s close enough to be pressed into service 
(historical Christian theology has to be full of words for similar ideas, 
right?); as I said; it’s just the first one that came to mind. Maybe something 
longer like has_same_elements would be better. But I would be a little 
surprised if any really common single word got the idea across.

> that doesn't add clarity or 
> precision and can only add confusion. Outside of the tiny niche of 
> people trying to prove the foundations of mathematics in first-order 
> logic and set theory, when mathematicians want to say two sets are 
> equal, they say they are equal, they don't use the term “coextensive”.

Sure, but in math, just as in Python, a set is never equal to a list (with a 
tiny foundations asterisk that isn’t relevant, but I’ll mention it below). 

So when mathematicians want to say a set is equal to a list… well, they just 
don’t say that, because it isn’t true, and usually isn’t even a meaningful 
question in the first place.

> See, for example, Mathworld, which uses "=" in the usual way:
> 
> https://mathworld.wolfram.com/Set.html

And in Python, it’s spelled “==“ instead of “=“, but otherwise, it already 
works the same way.

> and doesn't even have a definition for “coextensive”:
> 
> https://mathworld.wolfram.com/search/?query=coextensive=0=0

Sure. In fact, I suspect there’s no standard symbol or name for this operation. 
Just like there’s no standard name for “divisible by 3 but not by 2”, there’s 
no standard name for “not necessarily equal, but the sets of their respective 
elements are equal”. Those descriptions are way too long for method names even 
in Objective C, much less Python, but that doesn’t mean you can call a method 
for the former “isodd”, or the latter “isequal”, because those names more 
strongly imply a much more commonly useful operation than they do the one 
you’re intending.

Of course (both in math and in Python) probably you just write the 1-liner 
in-line, or maybe give it a “local” name and expect people to refer to the 
definition only 10 lines above. We only really need a good, meaningful, 
non-confusing name for this operation if it’s really important enough to add as 
a builtin method.

> The foundations of mathematics is one of those things which are 
> extremely over-represented on the Internet

Well, you’re the only one who brought up foundations here, and in the same 
email where you’re railing against people talking about foundations on the 
internet, so I’m not sure what the point is.

My guess is that you saw Greg, Marc-Andre, etc. talking about sets in 
mathematics and naturally thought “oh no, here comes irrelevant mathematical 
logic”, but there isn’t any; the reason sets came up is that we’re talking 
about set operations on Python set objects, and it’s pretty hard to talk about 
what issubset means/should mean without talking about sets. (And the message 
you’re replying to here doesn’t even do that; it’s just about the practical 
issues of equals methods in programming languages.)

But I’ll give it something to be retroactively sequitur to, that tiny asterisk 
mentioned above: When you’re dealing with foundations, you do often define 
everything, including lists, as sets, so picking one common set of definitions 
arbitrarily, {1,{1,{2,{2,3 = [1,2,3] is actually true. But that isn’t 
relevant, and wouldn’t be relevant even if all mathematicians were always 
worried about foundations and always used those particular definitions, because 
that obviously isn’t the operation the other Steve is looking for.

___
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