Re: [Python-ideas] install pip packages from Python prompt

[Terry Reedy]

On 10/31/2017 10:41 AM, Nick Coghlan wrote:
On 31 October 2017 at 05:57, Alex Walters 
> wrote:


> While I completely agree with this in principle, I think you
> overestimate the average beginner.


The average Python beginner may have a decade or more experience 
interacting with computers by voice, gestures, fingers on a screen, 
mouse clicks and movements, joystick controller clicks and movements, 
and single key presses.  This includes using a word processor.  They may 
or may not have consciously learned (or remember) anything about natural 
language grammar.  Python may well be their first experience with a 
formal language grammar and a picky interpreter.



Nope.  I totally get that they don’t know what a shell or command
prompt is.


A shell is a program in which users issue instructions one at a time as 
sentences in a formal language and wait for the response before issuing 
another.



  THEY. NEED. TO. LEARN.


Yes.  But what shell should people who want to learn Python learn first?

Interactive python, which comes with a 'using' manual besides a tutorial 
and two reference manuals?


Or, on Windows, Command Prompt, which runs a sparsely documented unnamed 
language, has no tutorial, and has mostly been replaced by File Explorer?


One can just as well or better learn the idea of a REPL with formal 
language input from Python first.  Once one has learned interactive 
Python, learning to use other shells should be straightforward.  It 
should not be too hard to convey that a different language with a 
different syntax and different built-in commands requires a different 
interpreter.



Hiding it is not a good idea for anyone.


Tell that to Microsoft, which in Win 10 removed command prompt and other 
'expert' tools from the regular start menu.


We're not in the business of making judgements about who should and 
shouldn't become Python programmers - we're in the business of making 
sure that Python is accessible to as many people as possible by removing 
irrelevant barriers to adoption, whether that's translating 
documentation so folks can start learning with instructions in their 
native language, or making it possible for them to defer learning the 
idiosyncrasies of the Windows, Linux, and Mac OS X command line 
environments.


My daughter learned Python and IDLE (from me) about 5 years before she 
had to learn about Command Prompt.  (In between, she had courses that 
used the Racket and Jave/Eclipse IDEs.)  The notion that she should have 
been forced to learn an inferior and useless (to her) shell first is to 
me absurd.


On the latter front, the details of the development interfaces offered 
by traditional desktop operating systems may *never* be relevant to the 
new generation of folks coming through that are learning to program by 
manipulating remote coding environments on tablets and other app-centric 
devices, just as most developers nowadays are able to get by without 
even learning C, let alone any flavour of assembly language. Our role in 
this process isn't to create future generations that think and work in 
exactly the same ways we do, it's to enable them to discover new ways of 
working that build on top of whatever we create.


Amen. At least 99+% of my interaction with the hg repository and my 
clones thereof was through TortoiseHg and its Workbench gui.



That means I now see a few potential RFEs from this thread:

1. An import system feature that allows a running Python program to 
report a timestamp (with the same granularity as pyc file timestamp 
headers) for *when* the currently loaded modules were last modified. 
This could be as simple as a new `__mtime__`  attribute in each module 
to store that number.
2. A new importlib.util API to check for potentially out of date modules 
in sys.modules (those where a freshly calculated module mtime doesn't 
match the stored __mtime__ attribute)



3. Support in IDLE for Jupyter-style "!" commands


I believe that this was suggested on idle-dev and rejected by Guido as 
an expert feature, or perhaps as abbreviating and thereby encouraging an 
expert usage.  I will let him say what he thinks now.


I have considered adding 'Run OS Command' to the Run menu, but I mostly 
do not see the point for a Python shell or REPL.  If one knows what to 
type after '!', one can just as well click the appropriate icon and 
enter the command there.  Or use os.system or subprocess.  What am I 
missing?


4. Having IDLE call that importlib API and warn about any stale modules 
after each command line operation


This seems heavy handed, usually unnecessary, but also inadequate.  One 
can now manipulate site-packages while running a Python shell in ways a 
shell will not know about.  One should then either start the shell 
manually or take the consequences.


As it is, IDLE restarts the user process each time one runs code from an 
editor.  Or one can explicitly 

Re: [Python-ideas] install pip packages from Python prompt

[Nick Coghlan]

On 1 November 2017 at 08:50, Terry Reedy  wrote:

> In April 2016, after posting the idea to pydev list and getting 'go
> ahead's from Nick Coughlin and someone else, with no negatives, I approved
> Upendra Kumar's GSOC proposal to write a pip gui.  This was
> https://bugs.python.org/issue27051.  On June 20, Ned Deily and Nick
> Coughlin vetoed adding a pip gui anywhere in the stdlib since it depended
> on something not in the stdlib, and perhaps for other reasons I don't fully
> understand.
>

Clarifying the objection here (since the linked issue is a fairly long
one): what I'm against is tightly coupling the pip-gui development &
release process to the CPython development & release process when we don't
have any compelling reason to do so.

While PEP 434 provides a workaround that helps to keep IDLE consistent
across different support branches, it still isn't as robust a development
model as folks being able to install an application and try it out on
existing Python versions *before* we bundle it with a CPython release.
https://packaging.python.org/tutorials/distributing-packages/ provides a
general guide on how to publish new packages, and the combination of tox
and Travis CI makes it reasonably straightforward to run pre-merge CI
testing across multiple Python versions.

Given an independently released pip-gui on PyPI (with its own version
numbering and release cadence), then I'd be +1 on bundling that as an
optional IDLE addon, ensurepip style. Such a project could also lay the
foundation for switching IDLE itself to a similar bundling model, which
would allow the need for PEP 434 to be eliminated as well (since bundled
applications are already permitted to add new features in maintenance
releases).

Cheers,
Nick.

P.S. I'll also note that a useful feature Travis CI offers is the ability
to automate PyPI releases: https://docs.travis-ci.com/user/deployment/pypi/

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[Nathaniel Smith]

On Oct 31, 2017 4:42 AM, "Nick Coghlan"  wrote:

On 31 October 2017 at 02:29, Guido van Rossum  wrote:

> What's your proposed process to arrive at the list of recommended packages?
>

I'm thinking it makes the most sense to treat inclusion in the recommended
packages list as a possible outcome of proposals for standard library
inclusion, rather than being something we'd provide a way to propose
specifically.

We'd only use it in cases where a proposal would otherwise meet the
criteria for stdlib inclusion, but the logistics of actually doing so don't
work for some reason.

Running the initial 5 proposals through that filter:

* six: a cross-version compatibility layer clearly needs to be outside the
standard library
* setuptools: we want to update this in line with the PyPA interop specs,
not the Python language version
* cffi: updates may be needed for PyPA interop specs, Python implementation
updates or C language definition updates
* requests: updates are more likely to be driven by changes in network
protocols and client platform APIs than Python language changes
* regex: we don't want two regex engines in the stdlib, transparently
replacing _sre would be difficult, and _sre is still good enough for most
purposes


Some other packages that might meet these criteria, or at least be useful
for honing them:

- lxml
- numpy
- cryptography
- idna

-n
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[Nick Coghlan]

On 1 November 2017 at 05:56, Guido van Rossum  wrote:

> On Tue, Oct 31, 2017 at 12:24 PM, MRAB  wrote:
>
>> At least Python 3.6 is only 1 year/release behind, which is fine!
>>
>
> OK, so presumably that argument doesn't preclude inclusion in the 3.7 (or
> later) stdlib. I'm beginning to warm up to the idea again... Maybe we
> should just bite the bullet. Nick, what do you think? Is it worth a small
> PEP?
>

I'm personally still in favour of swapping out the current _sre based
implementation for a _regex based implementation (such that 3.7+ still only
contained a single regex engine, and the stdlib re module and a PyPI regex
backport module could still happily coexist), and a PEP + draft patch would
be the way to do that.

The framing of a PEP for that approach would be "Replace the regex engine
backing the re module" rather than "Add regex to the standard library". The
existing engine could then potentially be spun out as a new "sre" project
on PyPI, such that folks that *were* depending on _sre internals had access
to an upgrade path that didn't necessarily require them porting their code
to a new regex engine (the PEP author wouldn't have to commit to doing that
work - we'd just ask the PyPI admins to reserve the name in case there
proved to be demand for such a project).

However, I'm also not one of the folks that would be on the hook for
handling any compatibility regressions that were subsequently reported
against the 3.7 re module, so I'd also take my +1 with a rather large grain
of salt - it's easy to be positive about a plan when the potential
downsides don't affect me personally :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] install pip packages from Python prompt

[Wes Turner]

You could teach them subprocess and os command injection safety from the
start:

```python
import subprocess
import sys
cmd = [sys.executable, -m', 'pip', 'install', '-r',
'psfblessed-requirements.txt'])
retcode = subprocess.check_call(cmd)
assert retcode == 0
```

(Because shell=True is dangerous and str.split is dangerous):

```python
filename = "'/etc/ passwd' ; shutdown -r now"
cmd = ("cat '%s'" % filename)
cmd
# "cat ''/etc/ passwd'' ; shutdown -r now"

cmd.split()
# ["'", '/etc', 'passwd', ';', 'shutdown', '-r', 'now']

shlex.split(cmd)
# ['cmd', '', '/etc', 'passwd', ';', 'shutdown', '-r', 'now']
```

(Sarge solves for a number of additional cases beyond shlex.split (empty
string should be '', 'already-quoted commands')

https://sarge.readthedocs.io/en/latest/overview.html#why-not-just-use-subprocess

 https://en.wikipedia.org/wiki/Code_injection#Shell_injection

https://sarge.readthedocs.io/en/latest/internals.html#how-shell-quoting-works

Of course, we're programmers and our input is not untrusted, so shell=True
without any string operations is not as dangerous.


On Tuesday, October 31, 2017, Wes Turner  wrote:

> You could teach them subprocess and os command injection safety from the
> start:
>
> ```python
> import subprocess
> import sys
> cmd = [sys.executable, -m', 'pip', 'install', '-r',
> 'psfblessed-requirements.txt'])
> retcode = subprocess.check_call(cmd)
> assert retcode == 0
> ```
>
> (Because shell=True is dangerous)
>
> On Tuesday, October 31, 2017, Terry Reedy  > wrote:
>
>> On 10/31/2017 12:21 PM, Ivan Levkivskyi wrote:
>>
>>> I think it was proposed several times before, but I just wanted to
>>> revive the idea that we could add
>>> a GUI interface to install/update packages from IDLE (maybe even with
>>> some package browser).
>>>
>>
>> https://bugs.python.org/issue23551.  I agreed with and still agree with
>> Raymond's opening message in Feb 2015:
>> "In teaching Python, I find that many Windows users are command-line
>> challenged and have difficulties using and accessing PIP. ... I would love
>> to be able to start a class with a fresh Python download from python.org
>> and effortlessly install requests and other tools without users having to
>> fire-up a terminal window and wrestle with the various parts."
>>
>> The one change I made in Raymond's proposal is that instead of having
>> multiple IDLE menu entries tied to multiple IDLE functions invoking
>> multiple pip functions, there would be one IDLE menu entry, perhaps 'Help
>> => Install packages' (plural intentional), that would invoke a standalone
>> tkinter based gui front-end to pip.  'Standalone' means no dependency on
>> IDLE code.  I don't think every IDE or app should *have to* write its own
>> gui.  Plus, a standalone tkinter module could be invoked from a command
>> line with 'python -m pipgui' or invoked from interactive python with
>> 'import pipgui; pipgui.main()'.
>>
>> In April 2016, after posting the idea to pydev list and getting 'go
>> ahead's from Nick Coughlin and someone else, with no negatives, I approved
>> Upendra Kumar's GSOC proposal to write a pip gui.  This was
>> https://bugs.python.org/issue27051.  On June 20, Ned Deily and Nick
>> Coughlin vetoed adding a pip gui anywhere in the stdlib since it depended
>> on something not in the stdlib, and perhaps for other reasons I don't fully
>> understand.
>>
>> Looking back, I can see that I made two mistakes.
>>
>> The first was proposing to use the public-looking pip.main after
>> importing pip.  It is actually intended to be private (and should have been
>> named '_main' to make that clearer).  As it turns out, the extra work of
>> accessing pip through the intended command line interface (via
>> subprocess) is necessary anyway since running pip makes changes to the
>> in-memory modules that are not reset when .main is called again.  So it
>> might as well be used for every access.
>>
>> The second was not requiring an approved PEP before proceeding to actual
>> coding.
>>
>> --
>> Terry Jan Reedy
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] install pip packages from Python prompt

[Wes Turner]

You could teach them subprocess and os command injection safety from the
start:

```python
import subprocess
import sys
cmd = [sys.executable, -m', 'pip', 'install', '-r',
'psfblessed-requirements.txt'])
retcode = subprocess.check_call(cmd)
assert retcode == 0
```

(Because shell=True is dangerous)

On Tuesday, October 31, 2017, Terry Reedy  wrote:

> On 10/31/2017 12:21 PM, Ivan Levkivskyi wrote:
>
>> I think it was proposed several times before, but I just wanted to revive
>> the idea that we could add
>> a GUI interface to install/update packages from IDLE (maybe even with
>> some package browser).
>>
>
> https://bugs.python.org/issue23551.  I agreed with and still agree with
> Raymond's opening message in Feb 2015:
> "In teaching Python, I find that many Windows users are command-line
> challenged and have difficulties using and accessing PIP. ... I would love
> to be able to start a class with a fresh Python download from python.org
> and effortlessly install requests and other tools without users having to
> fire-up a terminal window and wrestle with the various parts."
>
> The one change I made in Raymond's proposal is that instead of having
> multiple IDLE menu entries tied to multiple IDLE functions invoking
> multiple pip functions, there would be one IDLE menu entry, perhaps 'Help
> => Install packages' (plural intentional), that would invoke a standalone
> tkinter based gui front-end to pip.  'Standalone' means no dependency on
> IDLE code.  I don't think every IDE or app should *have to* write its own
> gui.  Plus, a standalone tkinter module could be invoked from a command
> line with 'python -m pipgui' or invoked from interactive python with
> 'import pipgui; pipgui.main()'.
>
> In April 2016, after posting the idea to pydev list and getting 'go
> ahead's from Nick Coughlin and someone else, with no negatives, I approved
> Upendra Kumar's GSOC proposal to write a pip gui.  This was
> https://bugs.python.org/issue27051.  On June 20, Ned Deily and Nick
> Coughlin vetoed adding a pip gui anywhere in the stdlib since it depended
> on something not in the stdlib, and perhaps for other reasons I don't fully
> understand.
>
> Looking back, I can see that I made two mistakes.
>
> The first was proposing to use the public-looking pip.main after importing
> pip.  It is actually intended to be private (and should have been named
> '_main' to make that clearer).  As it turns out, the extra work of
> accessing pip through the intended command line interface (via
> subprocess) is necessary anyway since running pip makes changes to the
> in-memory modules that are not reset when .main is called again.  So it
> might as well be used for every access.
>
> The second was not requiring an approved PEP before proceeding to actual
> coding.
>
> --
> Terry Jan Reedy
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] install pip packages from Python prompt

[Terry Reedy]

On 10/31/2017 12:21 PM, Ivan Levkivskyi wrote:
I think it was proposed several times before, but I just wanted to 
revive the idea that we could add
a GUI interface to install/update packages from IDLE (maybe even with 
some package browser).


https://bugs.python.org/issue23551.  I agreed with and still agree with 
Raymond's opening message in Feb 2015:
"In teaching Python, I find that many Windows users are command-line 
challenged and have difficulties using and accessing PIP. ... I would 
love to be able to start a class with a fresh Python download from 
python.org and effortlessly install requests and other tools without 
users having to fire-up a terminal window and wrestle with the various 
parts."


The one change I made in Raymond's proposal is that instead of having 
multiple IDLE menu entries tied to multiple IDLE functions invoking 
multiple pip functions, there would be one IDLE menu entry, perhaps 
'Help => Install packages' (plural intentional), that would invoke a 
standalone tkinter based gui front-end to pip.  'Standalone' means no 
dependency on IDLE code.  I don't think every IDE or app should *have 
to* write its own gui.  Plus, a standalone tkinter module could be 
invoked from a command line with 'python -m pipgui' or invoked from 
interactive python with 'import pipgui; pipgui.main()'.


In April 2016, after posting the idea to pydev list and getting 'go 
ahead's from Nick Coughlin and someone else, with no negatives, I 
approved Upendra Kumar's GSOC proposal to write a pip gui.  This was 
https://bugs.python.org/issue27051.  On June 20, Ned Deily and Nick 
Coughlin vetoed adding a pip gui anywhere in the stdlib since it 
depended on something not in the stdlib, and perhaps for other reasons I 
don't fully understand.


Looking back, I can see that I made two mistakes.

The first was proposing to use the public-looking pip.main after 
importing pip.  It is actually intended to be private (and should have 
been named '_main' to make that clearer).  As it turns out, the extra 
work of accessing pip through the intended command line interface (via
subprocess) is necessary anyway since running pip makes changes to the 
in-memory modules that are not reset when .main is called again.  So it 
might as well be used for every access.


The second was not requiring an approved PEP before proceeding to actual 
coding.


--
Terry Jan Reedy

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add single() to itertools

[Cameron Simpson]

On 31Oct2017 22:50, Greg Ewing  wrote:

Koos Zevenhoven wrote:

   |defsingle(i): try: ||v =i.next() 
|||exceptStopIteration:raiseException('No values')|||try: ||i.next() 
||exceptStopIteration: ||returnv||else: ||raiseException('Too many
   values')|||printsingle(name forname in('bob','fred')ifname=='bob')||| |

Looks like a clever method of whitespace compression to me. Those narrow 
vertical bars take up far less room that spaces!


And so convenient! No dependency on some parochial indentation size policy.
- Cameron
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] install pip packages from Python prompt

[Chris Barker]

On Tue, Oct 31, 2017 at 11:05 AM, Chris Angelico  wrote:

> > So I think defining a "pip" builtin that simply gave a helpful message
> would
> > be a good start.
> >
> > (hmm, it's a syntax error, so not as simple as a builtin -- but it could
> be
> > caught somehow to give a better message)
>
> This sounds like the job for an enhanced REPL like Jupyter/ipython. In
> fact, it might already exist - I haven't looked.
>

I jsu tlooked, no it doesn't -- but yes, a good idea for a feature request.

However, no matter how you slice it, some folks will be trying to to run
pip via the usual REPL, if we could get them a nice error, it would save a
lot of headaches and useless messages to mailing lists...

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[Guido van Rossum]

On Tue, Oct 31, 2017 at 12:24 PM, MRAB  wrote:

> On 2017-10-31 18:44, Guido van Rossum wrote:
>
>> On Tue, Oct 31, 2017 at 11:41 AM, MRAB > > wrote:
>>
>> regex gets updated when the Unicode Consortium releases an update.
>>
>>
>> Is it a feature that that is more frequently than Python releases? There
>> are other things in Python that must be updated whenever the UC releases an
>> update, and they get treated as features (or perhaps as bugfixes, I'm not
>> sure) but this means they generally don't get backported.
>>
>> Here's a list of the updates to Unicode:
>
> https://www.unicode.org/versions/enumeratedversions.html
>
> Roughly yearly.
>
> Those still on Python 2.7, for example, are now 8 years behind re Unicode.
>

Frankly I consider that a feature of the 2.7 end-of-life planning. :-)


> At least Python 3.6 is only 1 year/release behind, which is fine!
>

OK, so presumably that argument doesn't preclude inclusion in the 3.7 (or
later) stdlib. I'm beginning to warm up to the idea again... Maybe we
should just bite the bullet. Nick, what do you think? Is it worth a small
PEP?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] install pip packages from Python prompt

[Steve Barnes]

On 31/10/2017 18:05, Chris Angelico wrote:
> On Wed, Nov 1, 2017 at 2:49 AM, Chris Barker  wrote:
>> And sure, some of those are completly clueless about what a command line is
>> and how to use it, but others DO have an idea about the command line, but
>> dont know that:
>>
> pip install something
>>File "", line 1
>>  pip install something
>>^
>> SyntaxError: invalid syntax
>>
>> means: "this was supposed to be run at the command prompt"
>>
>> So I think defining a "pip" builtin that simply gave a helpful message would
>> be a good start.
>>
>> (hmm, it's a syntax error, so not as simple as a builtin -- but it could be
>> caught somehow to give a better message)
> 
> This sounds like the job for an enhanced REPL like Jupyter/ipython. In
> fact, it might already exist - I haven't looked.
> 
> ChrisA

Of course those in environments where they need to avoid the use of the 
shell could use ipython and simply start the session with:

  !pip install -U needed_package

before doing any imports.

-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect 
those of my employer.

---
This email has been checked for viruses by AVG.
http://www.avg.com

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[MRAB]

On 2017-10-31 18:44, Guido van Rossum wrote:
On Tue, Oct 31, 2017 at 11:41 AM, MRAB > wrote:


regex gets updated when the Unicode Consortium releases an update.


Is it a feature that that is more frequently than Python releases? 
There are other things in Python that must be updated whenever the UC 
releases an update, and they get treated as features (or perhaps as 
bugfixes, I'm not sure) but this means they generally don't get 
backported.



Here's a list of the updates to Unicode:

https://www.unicode.org/versions/enumeratedversions.html

Roughly yearly.

Those still on Python 2.7, for example, are now 8 years behind re Unicode.

At least Python 3.6 is only 1 year/release behind, which is fine!
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[Guido van Rossum]

On Tue, Oct 31, 2017 at 11:41 AM, MRAB  wrote:

> regex gets updated when the Unicode Consortium releases an update.
>

Is it a feature that that is more frequently than Python releases? There
are other things in Python that must be updated whenever the UC releases an
update, and they get treated as features (or perhaps as bugfixes, I'm not
sure) but this means they generally don't get backported.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[MRAB]

On 2017-10-31 11:42, Nick Coghlan wrote:
On 31 October 2017 at 02:29, Guido van Rossum > wrote:


What's your proposed process to arrive at the list of recommended
packages?


I'm thinking it makes the most sense to treat inclusion in the 
recommended packages list as a possible outcome of proposals for 
standard library inclusion, rather than being something we'd provide a 
way to propose specifically.


We'd only use it in cases where a proposal would otherwise meet the 
criteria for stdlib inclusion, but the logistics of actually doing so 
don't work for some reason.


Running the initial 5 proposals through that filter:

* six: a cross-version compatibility layer clearly needs to be outside 
the standard library
* setuptools: we want to update this in line with the PyPA interop 
specs, not the Python language version
* cffi: updates may be needed for PyPA interop specs, Python 
implementation updates or C language definition updates
* requests: updates are more likely to be driven by changes in network 
protocols and client platform APIs than Python language changes
* regex: we don't want two regex engines in the stdlib, transparently 
replacing _sre would be difficult, and _sre is still good enough for 
most purposes



regex gets updated when the Unicode Consortium releases an update.

[snip]
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] install pip packages from Python prompt

[Chris Angelico]

On Wed, Nov 1, 2017 at 2:49 AM, Chris Barker  wrote:
> And sure, some of those are completly clueless about what a command line is
> and how to use it, but others DO have an idea about the command line, but
> dont know that:
>
 pip install something
>   File "", line 1
> pip install something
>   ^
> SyntaxError: invalid syntax
>
> means: "this was supposed to be run at the command prompt"
>
> So I think defining a "pip" builtin that simply gave a helpful message would
> be a good start.
>
> (hmm, it's a syntax error, so not as simple as a builtin -- but it could be
> caught somehow to give a better message)

This sounds like the job for an enhanced REPL like Jupyter/ipython. In
fact, it might already exist - I haven't looked.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

[Steven D'Aprano]

On Tue, Oct 31, 2017 at 10:31:50AM +, אלעזר wrote:

> Off topic: why can't we simply allow something like this:
> 
> (the_bob) = (name for name in ('bob','fred') if name=='bob')

Parens don't make a tuple. They are just for grouping. If you want a 
tuple, you need a comma:

the_bob, = ...

with or without the parens. It would be terribly surprising if (x) was a 
sequence on the left hand side but not on the right hand side of an 
assignment.


> Why does Python treat the parenthesis at the LHS as grouping parens?
> operators are not allowed anyway; (a + (b + c)) = [1] is syntax error.

a, (b, c), d = [1, "xy", 2]



> Currently
> 
> (x) = 1
> 
> works, but I can't see why should it.

Why shouldn't it?

Its just a trivial case of the fact that the left hand side can be 
certain kinds of expressions, some of which require parens:

(spam or ham)[x] = value

There are lots of possible expressions allowed on the LHS, and no good 
reason to prohibit (x) even though its pointless.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[Wes Turner]

On Tuesday, October 31, 2017, Guido van Rossum  wrote:

> On Tue, Oct 31, 2017 at 4:42 AM, Nick Coghlan  > wrote:
>
>> On 31 October 2017 at 02:29, Guido van Rossum > > wrote:
>>
>>> What's your proposed process to arrive at the list of recommended
>>> packages?
>>>
>>
>> I'm thinking it makes the most sense to treat inclusion in the
>> recommended packages list as a possible outcome of proposals for standard
>> library inclusion, rather than being something we'd provide a way to
>> propose specifically.
>>
>
> I don't think that gets you off the hook for a process proposal. We need
> some criteria to explain why a module should be on the recommended list --
> not just a ruling as to why it shouldn't be in the stdlib.
>
>
>> We'd only use it in cases where a proposal would otherwise meet the
>> criteria for stdlib inclusion, but the logistics of actually doing so don't
>> work for some reason.
>>
>
> But that would exclude most of the modules you mention below, since one of
> the criteria is that their development speed be matched with Python's
> release cycle. I think there must be some form of "popularity" combined
> with "best of breed". In particular I'd like to have a rule that explains
> why flask and Django would never make the list. (I don't know what that
> rule is, or I would tell you -- my gut tells me it's something to do with
> having their own community *and* competing for the same spot.)
>
> Running the initial 5 proposals through that filter:
>>
>> * six: a cross-version compatibility layer clearly needs to be outside
>> the standard library
>>
>
> Hm... Does six still change regularly? If not I think it *would* be a
> candidate for actual stdlib inclusion. Just like we added u"..." literals
> to Python 3.4.
>
>
>> * setuptools: we want to update this in line with the PyPA interop specs,
>> not the Python language version
>>
>
> But does that exclude stdlib inclusion? Why would those specs change, and
> why couldn't they wait for a new Python release?
>
>
>> * cffi: updates may be needed for PyPA interop specs, Python
>> implementation updates or C language definition updates
>>
>
> Hm, again, I don't recall that this was debated -- I think it's a failure
> that it's not in the stdlib.
>
>
>> * requests: updates are more likely to be driven by changes in network
>> protocols and client platform APIs than Python language changes
>>
>
> Here I agree. There's no alternative (except aiohttp, but that's
> asyncio-based) and it can't be in the stdlib because it's actively being
> developed.
>

What about certifi (SSL bundles (from requests (?)) on PyPi)
https://pypi.org/project/certifi/ ?


>
>
>> * regex: we don't want two regex engines in the stdlib, transparently
>> replacing _sre would be difficult, and _sre is still good enough for most
>> purposes
>>
>
> I think this needn't be recommended at all. For 99.9% of regular
> expression uses, re is just fine. Let's just work on a strategy for
> introducing regex into the stdlib.
>
>
>> Of the 5, I'd suggest that regex is the only one that could potentially
>> still make its way into the standard library some day - it would just
>> require someone with both the time and inclination to create a CPython
>> variant that used _regex instead of _sre as the default regex engine, and
>> then gathered evidence to show that it was "compatible enough" with _sre to
>> serve as the default engine for CPython.
>>
>> For the first four, there are compelling arguments that their drivers for
>> new feature additions are such that their release cycles shouldn't ever be
>> tied to the rate at which we update the Python language definition.
>>
>
> As you can tell from my arguing, the reasons need to be written up in more
> detail.
>
>
>> And is it really just going to be a list of names, or is there going to
>>> be some documentation (about the vetting, not about the contents of the
>>> packages) for each name?
>>>
>>
>> I'm thinking a new subsection in https://docs.python.org/devgui
>> de/stdlibchanges.html for "Recommended Third Party Packages" would make
>> sense, covering what I wrote above.
>>
>
> That's too well hidden for my taste.
>
>
>> It also occurred to me that since the recommendations are independent of
>> the Python version, they don't really belong in the version specific
>> documentation.
>>
>
> But that doesn't mean they can't (also) be listed there. (And each
> probably has its version dependencies.)
>
>
>> While the Developer's Guide isn't really the right place for the list
>> either (except as an easier way to answer "Why isn't  in the standard
>> library?" questions), it could be a good interim option until I get around
>> to actually writing a first draft of https://github.com/python/redi
>> stributor-guide/ (which I was talking to Barry about at the dev sprint,
>> but didn't end up 

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[Guido van Rossum]

OK, go ahead and write the PEP! I'm actually happy with the responses you
gave, so your last email will make a good start for some of the contents of
the PEP.

On Tue, Oct 31, 2017 at 9:19 AM, Nick Coghlan  wrote:

> On 1 November 2017 at 00:53, Guido van Rossum  wrote:
>
>> On Tue, Oct 31, 2017 at 4:42 AM, Nick Coghlan  wrote:
>>
>>> On 31 October 2017 at 02:29, Guido van Rossum  wrote:
>>>
 What's your proposed process to arrive at the list of recommended
 packages?

>>>
>>> I'm thinking it makes the most sense to treat inclusion in the
>>> recommended packages list as a possible outcome of proposals for standard
>>> library inclusion, rather than being something we'd provide a way to
>>> propose specifically.
>>>
>>
>> I don't think that gets you off the hook for a process proposal. We need
>> some criteria to explain why a module should be on the recommended list --
>> not just a ruling as to why it shouldn't be in the stdlib.
>>
>
> The developer guide already has couple of sections on this aspect:
>
> * https://devguide.python.org/stdlibchanges/#acceptable-types-of-modules
> * https://devguide.python.org/stdlibchanges/#requirements
>
> I don't think either of those sections is actually quite right (since
> we've approved new modules that wouldn't meet them), but they're not
> terrible as a starting point in general, and they're accurate for the
> recommended packages use case.
>
>
>> We'd only use it in cases where a proposal would otherwise meet the
>>> criteria for stdlib inclusion, but the logistics of actually doing so don't
>>> work for some reason.
>>>
>>
>> But that would exclude most of the modules you mention below, since one
>> of the criteria is that their development speed be matched with Python's
>> release cycle. I think there must be some form of "popularity" combined
>> with "best of breed". In particular I'd like to have a rule that explains
>> why flask and Django would never make the list. (I don't know what that
>> rule is, or I would tell you -- my gut tells me it's something to do with
>> having their own community *and* competing for the same spot.)
>>
>
> The developer guide words this as "The module needs to be considered
> best-of-breed.". In some categories (like WSGI frameworks), there are
> inherent trade-offs that mean there will *never* be a single best-of-breed
> solution, since projects like Django, Flask, and Pyramid occupy
> deliberately different points in the space of available design decisions.
>
> Running the initial 5 proposals through that filter:
>>>
>>> * six: a cross-version compatibility layer clearly needs to be outside
>>> the standard library
>>>
>>
>> Hm... Does six still change regularly? If not I think it *would* be a
>> candidate for actual stdlib inclusion. Just like we added u"..." literals
>> to Python 3.4.
>>
>
> It still changes as folks porting new projects discover additional
> discrepancies between the 2.x and 3.x standard library layouts and
> behaviour (e.g. we found recently that the 3.x subprocess module's
> emulation of the old commands module APIs actually bit shifts the status
> codes relative to the 2.7 versions). The rate of change has definitely
> slowed down a lot since the early days, but it isn't zero.
>
> In addition, the only folks that need it are those that already care about
> older versions of Python - if you can start with whatever the latest
> version of Python is, and don't have any reason to support users still
> running older version, you can happily pretend those older versions don't
> exist, and hence don't need a compatibility library like six. As a separate
> library, it can just gracefully fade away as folks stop depending on it as
> they drop Python 2.7 support. By contrast, if we were to bring it into the
> 3.x standard library, then we'd eventually have to figure out when we could
> deprecate and remove it again.
>
>
>> * setuptools: we want to update this in line with the PyPA interop specs,
>>> not the Python language version
>>>
>>
>> But does that exclude stdlib inclusion? Why would those specs change, and
>> why couldn't they wait for a new Python release?
>>
>
> The specs mainly change when we want to offer publishers new capabilities
> while still maintaining compatibility with older installation clients (and
> vice-versa: we want folks still running Python 2.7 to be able to publish
> wheel files and use recently added metadata fields like
> Description-Content-Type).
>
> The reason we can't wait for new Python releases is because when we add
> such things, we need them to work on *all* supported Python releases
> (including 2.7 and security-release-only 3.x versions).
>
> There are also other drivers for setuptools updates, which include:
>
> - operating system build toolchain changes (e.g. finding new versions of
> Visual Studio or XCode)
> - changes to PyPI's operations (e.g. the legacy upload API getting turned

Re: [Python-ideas] install pip packages from Python prompt

[Ivan Levkivskyi]

I think it was proposed several times before, but I just wanted to revive
the idea that we could add
a GUI interface to install/update packages from IDLE (maybe even with some
package browser).

--
Ivan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[Nick Coghlan]

On 1 November 2017 at 00:53, Guido van Rossum  wrote:

> On Tue, Oct 31, 2017 at 4:42 AM, Nick Coghlan  wrote:
>
>> On 31 October 2017 at 02:29, Guido van Rossum  wrote:
>>
>>> What's your proposed process to arrive at the list of recommended
>>> packages?
>>>
>>
>> I'm thinking it makes the most sense to treat inclusion in the
>> recommended packages list as a possible outcome of proposals for standard
>> library inclusion, rather than being something we'd provide a way to
>> propose specifically.
>>
>
> I don't think that gets you off the hook for a process proposal. We need
> some criteria to explain why a module should be on the recommended list --
> not just a ruling as to why it shouldn't be in the stdlib.
>

The developer guide already has couple of sections on this aspect:

* https://devguide.python.org/stdlibchanges/#acceptable-types-of-modules
* https://devguide.python.org/stdlibchanges/#requirements

I don't think either of those sections is actually quite right (since we've
approved new modules that wouldn't meet them), but they're not terrible as
a starting point in general, and they're accurate for the recommended
packages use case.


> We'd only use it in cases where a proposal would otherwise meet the
>> criteria for stdlib inclusion, but the logistics of actually doing so don't
>> work for some reason.
>>
>
> But that would exclude most of the modules you mention below, since one of
> the criteria is that their development speed be matched with Python's
> release cycle. I think there must be some form of "popularity" combined
> with "best of breed". In particular I'd like to have a rule that explains
> why flask and Django would never make the list. (I don't know what that
> rule is, or I would tell you -- my gut tells me it's something to do with
> having their own community *and* competing for the same spot.)
>

The developer guide words this as "The module needs to be considered
best-of-breed.". In some categories (like WSGI frameworks), there are
inherent trade-offs that mean there will *never* be a single best-of-breed
solution, since projects like Django, Flask, and Pyramid occupy
deliberately different points in the space of available design decisions.

Running the initial 5 proposals through that filter:
>>
>> * six: a cross-version compatibility layer clearly needs to be outside
>> the standard library
>>
>
> Hm... Does six still change regularly? If not I think it *would* be a
> candidate for actual stdlib inclusion. Just like we added u"..." literals
> to Python 3.4.
>

It still changes as folks porting new projects discover additional
discrepancies between the 2.x and 3.x standard library layouts and
behaviour (e.g. we found recently that the 3.x subprocess module's
emulation of the old commands module APIs actually bit shifts the status
codes relative to the 2.7 versions). The rate of change has definitely
slowed down a lot since the early days, but it isn't zero.

In addition, the only folks that need it are those that already care about
older versions of Python - if you can start with whatever the latest
version of Python is, and don't have any reason to support users still
running older version, you can happily pretend those older versions don't
exist, and hence don't need a compatibility library like six. As a separate
library, it can just gracefully fade away as folks stop depending on it as
they drop Python 2.7 support. By contrast, if we were to bring it into the
3.x standard library, then we'd eventually have to figure out when we could
deprecate and remove it again.


> * setuptools: we want to update this in line with the PyPA interop specs,
>> not the Python language version
>>
>
> But does that exclude stdlib inclusion? Why would those specs change, and
> why couldn't they wait for a new Python release?
>

The specs mainly change when we want to offer publishers new capabilities
while still maintaining compatibility with older installation clients (and
vice-versa: we want folks still running Python 2.7 to be able to publish
wheel files and use recently added metadata fields like
Description-Content-Type).

The reason we can't wait for new Python releases is because when we add
such things, we need them to work on *all* supported Python releases
(including 2.7 and security-release-only 3.x versions).

There are also other drivers for setuptools updates, which include:

- operating system build toolchain changes (e.g. finding new versions of
Visual Studio or XCode)
- changes to PyPI's operations (e.g. the legacy upload API getting turned
off due to persistent service stability problems, switching to HTTPS only
access)

With setuptools as a separate project, a whole lot of package publication
problems can be solved via "pip install --upgrade setuptools wheel" in a
virtual environment, which is a luxury we don't have with plain distutils.


>  * cffi: updates may be needed for PyPA interop specs, Python
> 

Re: [Python-ideas] install pip packages from Python prompt

[Chris Barker]

oops, hit the send button too soon...

here's some more:

On Tue, Oct 31, 2017 at 8:41 AM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

>
>
>> Nope.  I totally get that they don’t know what a shell or command prompt
>> is.  THEY. NEED. TO. LEARN.  Hiding it is not a good idea for anyone.
>
>
> I actually take this approach myself in my classes. However, I also have
> as prerequisites for my classes:
>
> Some Experience in some programming language
>
> And
>
> Basic familiarity with the command line.
>
> I then let them use whatever dev. Environment they want, while supporting
> and recommending a good editor and the command line.
>
> However, If people want to learn python that don’t have those
> prerequisites, then we suggest a different class designed for total newbies.
>
> In THAT class,  we use a more proscribed dev environment so that everyone
> is doing the same thing in the same way. It was IDLE, and has lately been
> PyCharm.
>
> And the intro to data analytics class uses Anaconda and the Jupyter
> notebook.
>
> My point?
>
> We're not in the business of making judgements about who should and
> shouldn't become Python programmers - we're in the business of making sure
> that Python is accessible to as many people as possible by removing
> irrelevant barriers to adoption,
>
>
> Sure, but who is “we”? I think “we” is the python community, not the
> cPython developers.
>
> So providing an environment that makes it easy and obvious to install
> packages is a great idea, but I think it’s the job of IDEs and other higher
> level tools, not the REPL.
>
> If we need to add a feature to Python itself to make it easier for IDEs
> and the like to implement dynamic package adding, then by all means, let’s
> do it.
>
> Final note:
>
> I DO see a lot of questions ( on mailing lists, etc) from folks that try
> to type “pip install something” at the python command line.
>

And sure, some of those are completly clueless about what a command line is
and how to use it, but others DO have an idea about the command line, but
dont know that:

>>> pip install something
  File "", line 1
pip install something
  ^
SyntaxError: invalid syntax

means: "this was supposed to be run at the command prompt"

So I think defining a "pip" builtin that simply gave a helpful message
would be a good start.

(hmm, it's a syntax error, so not as simple as a builtin -- but it could be
caught somehow to give a better message)

At the end of the day, python is an open source programming language -- it
simply is NOT ever going to provide one complete well integrated
environment --we'll just have to live with that.

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] install pip packages from Python prompt

[Chris Barker - NOAA Federal]

> Nope.  I totally get that they don’t know what a shell or command prompt
> is.  THEY. NEED. TO. LEARN.  Hiding it is not a good idea for anyone.


I actually take this approach myself in my classes. However, I also have as
prerequisites for my classes:

Some Experience in some programming language

And

Basic familiarity with the command line.

I then let them use whatever dev. Environment they want, while supporting
and recommending a good editor and the command line.

However, If people want to learn python that don’t have those
prerequisites, then we suggest a different class designed for total newbies.

In THAT class,  we use a more proscribed dev environment so that everyone
is doing the same thing in the same way. It was IDLE, and has lately been
PyCharm.

And the intro to data analytics class uses Anaconda and the Jupyter
notebook.

My point?

We're not in the business of making judgements about who should and
shouldn't become Python programmers - we're in the business of making sure
that Python is accessible to as many people as possible by removing
irrelevant barriers to adoption,


Sure, but who is “we”? I think “we” is the python community, not the
cPython developers.

So providing an environment that makes it easy and obvious to install
packages is a great idea, but I think it’s the job of IDEs and other higher
level tools, not the REPL.

If we need to add a feature to Python itself to make it easier for IDEs and
the like to implement dynamic package adding, then by all means, let’s do
it.

Final note:

I DO see a lot of questions ( on mailing lists, etc) from folks that try to
type “pip install something” at the python command line.



whether that's translating documentation so folks can start learning with
instructions in their native language, or making it possible for them to
defer learning the idiosyncrasies of the Windows, Linux, and Mac OS X
command line environments.

On the latter front, the details of the development interfaces offered by
traditional desktop operating systems may *never* be relevant to the new
generation of folks coming through that are learning to program by
manipulating remote coding environments on tablets and other app-centric
devices, just as most developers nowadays are able to get by without even
learning C, let alone any flavour of assembly language. Our role in this
process isn't to create future generations that think and work in exactly
the same ways we do, it's to enable them to discover new ways of working
that build on top of whatever we create.

Jupyter notebooks are a decent example of this, where the difference
between a Python statement and a "command line statement" is just an
exclamation mark at the beginning of the line - exactly where the backing
environment lives is mostly a hidden implementation detail from the user's
perspective.

Eclipse Che and other online coding environments are another case - there,
the "command line" is a different window inside the editor app (this is
also going to be a familiar option for heavy IDE users on traditional
desktop operating systems).

And putting it in those terms makes me think that we should explicitly
exclude the default REPL from consideration here, as we've long taken the
position that that *isn't* a good teaching environment, and you certainly
can't access it remotely without some kind of other service in front of it
to manage the network connection (even if that service is just ssh).

That means I now see a few potential RFEs from this thread:

1. An import system feature that allows a running Python program to report
a timestamp (with the same granularity as pyc file timestamp headers) for
*when* the currently loaded modules were last modified. This could be as
simple as a new `__mtime__`  attribute in each module to store that number.
2. A new importlib.util API to check for potentially out of date modules in
sys.modules (those where a freshly calculated module mtime doesn't match
the stored __mtime__ attribute)
3. Support in IDLE for Jupyter-style "!" commands
4. Having IDLE call that importlib API and warn about any stale modules
after each command line operation

The first two features would be about enabling learning environments to
more easily detect when the currently loaded modules may not match what's
actually on disk (hot reloaders already do this by watching for filesystem
changes, but we're currently missing a simpler polling based alternative
that will also pick up package updates).

The second two would be about enhancing IDLE's capabilities in this area,
as we *do* suggest that as a reasonable initial learning environment, even
though there are also plenty of alternatives out there now.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[Guido van Rossum]

On Tue, Oct 31, 2017 at 4:42 AM, Nick Coghlan  wrote:

> On 31 October 2017 at 02:29, Guido van Rossum  wrote:
>
>> What's your proposed process to arrive at the list of recommended
>> packages?
>>
>
> I'm thinking it makes the most sense to treat inclusion in the recommended
> packages list as a possible outcome of proposals for standard library
> inclusion, rather than being something we'd provide a way to propose
> specifically.
>

I don't think that gets you off the hook for a process proposal. We need
some criteria to explain why a module should be on the recommended list --
not just a ruling as to why it shouldn't be in the stdlib.


> We'd only use it in cases where a proposal would otherwise meet the
> criteria for stdlib inclusion, but the logistics of actually doing so don't
> work for some reason.
>

But that would exclude most of the modules you mention below, since one of
the criteria is that their development speed be matched with Python's
release cycle. I think there must be some form of "popularity" combined
with "best of breed". In particular I'd like to have a rule that explains
why flask and Django would never make the list. (I don't know what that
rule is, or I would tell you -- my gut tells me it's something to do with
having their own community *and* competing for the same spot.)

Running the initial 5 proposals through that filter:
>
> * six: a cross-version compatibility layer clearly needs to be outside the
> standard library
>

Hm... Does six still change regularly? If not I think it *would* be a
candidate for actual stdlib inclusion. Just like we added u"..." literals
to Python 3.4.


> * setuptools: we want to update this in line with the PyPA interop specs,
> not the Python language version
>

But does that exclude stdlib inclusion? Why would those specs change, and
why couldn't they wait for a new Python release?


> * cffi: updates may be needed for PyPA interop specs, Python
> implementation updates or C language definition updates
>

Hm, again, I don't recall that this was debated -- I think it's a failure
that it's not in the stdlib.


> * requests: updates are more likely to be driven by changes in network
> protocols and client platform APIs than Python language changes
>

Here I agree. There's no alternative (except aiohttp, but that's
asyncio-based) and it can't be in the stdlib because it's actively being
developed.


> * regex: we don't want two regex engines in the stdlib, transparently
> replacing _sre would be difficult, and _sre is still good enough for most
> purposes
>

I think this needn't be recommended at all. For 99.9% of regular expression
uses, re is just fine. Let's just work on a strategy for introducing regex
into the stdlib.


> Of the 5, I'd suggest that regex is the only one that could potentially
> still make its way into the standard library some day - it would just
> require someone with both the time and inclination to create a CPython
> variant that used _regex instead of _sre as the default regex engine, and
> then gathered evidence to show that it was "compatible enough" with _sre to
> serve as the default engine for CPython.
>
> For the first four, there are compelling arguments that their drivers for
> new feature additions are such that their release cycles shouldn't ever be
> tied to the rate at which we update the Python language definition.
>

As you can tell from my arguing, the reasons need to be written up in more
detail.


> And is it really just going to be a list of names, or is there going to be
>> some documentation (about the vetting, not about the contents of the
>> packages) for each name?
>>
>
> I'm thinking a new subsection in https://docs.python.org/
> devguide/stdlibchanges.html for "Recommended Third Party Packages" would
> make sense, covering what I wrote above.
>

That's too well hidden for my taste.


> It also occurred to me that since the recommendations are independent of
> the Python version, they don't really belong in the version specific
> documentation.
>

But that doesn't mean they can't (also) be listed there. (And each probably
has its version dependencies.)


> While the Developer's Guide isn't really the right place for the list
> either (except as an easier way to answer "Why isn't  in the standard
> library?" questions), it could be a good interim option until I get around
> to actually writing a first draft of https://github.com/python/
> redistributor-guide/ (which I was talking to Barry about at the dev
> sprint, but didn't end up actually creating any content for since I went
> down a signal handling rabbit hole instead).
>

Hm, let's not put more arbitrary check boxes in the way of progress. Maybe
it can be an informational PEP that's occasionally updated?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of 

Re: [Python-ideas] install pip packages from Python prompt

[Nick Coghlan]

On 31 October 2017 at 05:57, Alex Walters  wrote:

> > While I completely agree with this in principle, I think you
> > overestimate the average beginner.
>
> Nope.  I totally get that they don’t know what a shell or command prompt
> is.  THEY. NEED. TO. LEARN.  Hiding it is not a good idea for anyone.  If
> this is an insurmountable problem for the newbie, maybe they really
> shouldn’t be attempting to program.  This field is not for everyone.
>

We're not in the business of making judgements about who should and
shouldn't become Python programmers - we're in the business of making sure
that Python is accessible to as many people as possible by removing
irrelevant barriers to adoption, whether that's translating documentation
so folks can start learning with instructions in their native language, or
making it possible for them to defer learning the idiosyncrasies of the
Windows, Linux, and Mac OS X command line environments.

On the latter front, the details of the development interfaces offered by
traditional desktop operating systems may *never* be relevant to the new
generation of folks coming through that are learning to program by
manipulating remote coding environments on tablets and other app-centric
devices, just as most developers nowadays are able to get by without even
learning C, let alone any flavour of assembly language. Our role in this
process isn't to create future generations that think and work in exactly
the same ways we do, it's to enable them to discover new ways of working
that build on top of whatever we create.

Jupyter notebooks are a decent example of this, where the difference
between a Python statement and a "command line statement" is just an
exclamation mark at the beginning of the line - exactly where the backing
environment lives is mostly a hidden implementation detail from the user's
perspective.

Eclipse Che and other online coding environments are another case - there,
the "command line" is a different window inside the editor app (this is
also going to be a familiar option for heavy IDE users on traditional
desktop operating systems).

And putting it in those terms makes me think that we should explicitly
exclude the default REPL from consideration here, as we've long taken the
position that that *isn't* a good teaching environment, and you certainly
can't access it remotely without some kind of other service in front of it
to manage the network connection (even if that service is just ssh).

That means I now see a few potential RFEs from this thread:

1. An import system feature that allows a running Python program to report
a timestamp (with the same granularity as pyc file timestamp headers) for
*when* the currently loaded modules were last modified. This could be as
simple as a new `__mtime__`  attribute in each module to store that number.
2. A new importlib.util API to check for potentially out of date modules in
sys.modules (those where a freshly calculated module mtime doesn't match
the stored __mtime__ attribute)
3. Support in IDLE for Jupyter-style "!" commands
4. Having IDLE call that importlib API and warn about any stale modules
after each command line operation

The first two features would be about enabling learning environments to
more easily detect when the currently loaded modules may not match what's
actually on disk (hot reloaders already do this by watching for filesystem
changes, but we're currently missing a simpler polling based alternative
that will also pick up package updates).

The second two would be about enhancing IDLE's capabilities in this area,
as we *do* suggest that as a reasonable initial learning environment, even
though there are also plenty of alternatives out there now.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add single() to itertools

[Soni L.]

On 2017-10-31 10:58 AM, Joao S. O. Bueno wrote:

On 31 October 2017 at 10:52, Steven D'Aprano  wrote:

On Tue, Oct 31, 2017 at 10:42:23AM -0200, Joao S. O. Bueno wrote:

When I need something like this, I usually rop a line on the module
namespace that goes like:

first = lambda x: next(iter(x))

That doesn't meet the requirement that x has ONLY one item.

And using lambda like that is bad style. This would be better:

def first(x): return next(iter(x))

and now first has a proper __name__.


I know that. But then, I'd rather write it as  3-4 lines in some utils module.

So, although I was initially -1 to -0 on this suggestion, maybe it has a point.


Plop this one-liner somewhere: exec('def single(x):\n [v] = x\n return v')






--
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add single() to itertools

[Joao S. O. Bueno]

On 31 October 2017 at 10:52, Steven D'Aprano  wrote:
> On Tue, Oct 31, 2017 at 10:42:23AM -0200, Joao S. O. Bueno wrote:
>> When I need something like this, I usually rop a line on the module
>> namespace that goes like:
>>
>> first = lambda x: next(iter(x))
>
> That doesn't meet the requirement that x has ONLY one item.
>
> And using lambda like that is bad style. This would be better:
>
> def first(x): return next(iter(x))
>
> and now first has a proper __name__.


I know that. But then, I'd rather write it as  3-4 lines in some utils module.

So, although I was initially -1 to -0 on this suggestion, maybe it has a point.

>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add single() to itertools

[Steven D'Aprano]

On Tue, Oct 31, 2017 at 10:42:23AM -0200, Joao S. O. Bueno wrote:
> When I need something like this, I usually rop a line on the module
> namespace that goes like:
> 
> first = lambda x: next(iter(x))

That doesn't meet the requirement that x has ONLY one item.

And using lambda like that is bad style. This would be better:

def first(x): return next(iter(x))

and now first has a proper __name__.



-- 
Steve
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add single() to itertools

[Joao S. O. Bueno]

When I need something like this, I usually rop a line on the module
namespace that goes like:

first = lambda x: next(iter(x))


On 30 October 2017 at 23:09, Steven D'Aprano  wrote:
> On Tue, Oct 31, 2017 at 07:51:02AM +1100, Cameron Simpson wrote:
>
>>  return the(nodes)
>>
>> It's this kind of thing that expresses my intent better than the:
>>
>>  node, = nodes
>>  return node
>>
>> idiom.
>
> If the intent is to indicate that there is only one node, then
> "the(nodes)" fails completely. "The" can refer to plurals as easily as
> singular:
>
> "Wash the dirty clothes."
> (Later) "Why did you only wash one sock?"
>
>
> The simplest implementation of this "single()" function I can think of
> would be:
>
> def single(iterable):
> result, = iterable
> return result
>
>
> That raises ValueError if iterable has too few or too many items, which
> I believe is the right exception to use. Conceptually, there's no
> indexing involved, so IndexError would be the wrong exception to use.
> We're expecting a compound value (an iterable) with exactly one item. If
> there's not exactly one item, that's a ValueError.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"

[Nick Coghlan]

On 31 October 2017 at 02:29, Guido van Rossum  wrote:

> What's your proposed process to arrive at the list of recommended packages?
>

I'm thinking it makes the most sense to treat inclusion in the recommended
packages list as a possible outcome of proposals for standard library
inclusion, rather than being something we'd provide a way to propose
specifically.

We'd only use it in cases where a proposal would otherwise meet the
criteria for stdlib inclusion, but the logistics of actually doing so don't
work for some reason.

Running the initial 5 proposals through that filter:

* six: a cross-version compatibility layer clearly needs to be outside the
standard library
* setuptools: we want to update this in line with the PyPA interop specs,
not the Python language version
* cffi: updates may be needed for PyPA interop specs, Python implementation
updates or C language definition updates
* requests: updates are more likely to be driven by changes in network
protocols and client platform APIs than Python language changes
* regex: we don't want two regex engines in the stdlib, transparently
replacing _sre would be difficult, and _sre is still good enough for most
purposes

Of the 5, I'd suggest that regex is the only one that could potentially
still make its way into the standard library some day - it would just
require someone with both the time and inclination to create a CPython
variant that used _regex instead of _sre as the default regex engine, and
then gathered evidence to show that it was "compatible enough" with _sre to
serve as the default engine for CPython.

For the first four, there are compelling arguments that their drivers for
new feature additions are such that their release cycles shouldn't ever be
tied to the rate at which we update the Python language definition.


> And is it really just going to be a list of names, or is there going to be
> some documentation (about the vetting, not about the contents of the
> packages) for each name?
>

I'm thinking a new subsection in
https://docs.python.org/devguide/stdlibchanges.html for "Recommended Third
Party Packages" would make sense, covering what I wrote above.

It also occurred to me that since the recommendations are independent of
the Python version, they don't really belong in the version specific
documentation.

While the Developer's Guide isn't really the right place for the list
either (except as an easier way to answer "Why isn't  in the standard
library?" questions), it could be a good interim option until I get around
to actually writing a first draft of
https://github.com/python/redistributor-guide/ (which I was talking to
Barry about at the dev sprint, but didn't end up actually creating any
content for since I went down a signal handling rabbit hole instead).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

[אלעזר]

On Tue, Oct 31, 2017 at 12:18 PM Koos Zevenhoven  wrote:

> On Tue, Oct 31, 2017 at 11:24 AM, Petr Viktorin  wrote:
>
>> On 10/31/2017 09:54 AM, Koos Zevenhoven wrote:
>>>
>>>
>>> ​I wonder if that's more easily understood if you write it along these
>>> line(s):
>>>
>>>(the_bob,) = ​(name for name in ('bob','fred') if name=='bob')
>>>
>>
>> There are (unfortunately) several ways to do it. I prefer one that avoids
>> a trailing comma:
>>
>> [the_bob] = ​(name for name in ('bob','fred') if name=='bob')
>>
>>
> ​Maybe it's just me, but somehow that list-like syntax as an assignment
> target feels wrong in somewhat the same way that (1, 2).append(3) does.​
>
>
Off topic: why can't we simply allow something like this:

(the_bob) = (name for name in ('bob','fred') if name=='bob')

Why does Python treat the parenthesis at the LHS as grouping parens?
operators are not allowed anyway; (a + (b + c)) = [1] is syntax error.

Currently

(x) = 1

works, but I can't see why should it.

Elazar
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

[Koos Zevenhoven]

On Tue, Oct 31, 2017 at 11:24 AM, Petr Viktorin  wrote:

> On 10/31/2017 09:54 AM, Koos Zevenhoven wrote:
>>
>>
>> ​I wonder if that's more easily understood if you write it along these
>> line(s):
>>
>>(the_bob,) = ​(name for name in ('bob','fred') if name=='bob')
>>
>
> There are (unfortunately) several ways to do it. I prefer one that avoids
> a trailing comma:
>
> [the_bob] = ​(name for name in ('bob','fred') if name=='bob')
>
>
​Maybe it's just me, but somehow that list-like syntax as an assignment
target feels wrong in somewhat the same way that (1, 2).append(3) does.​

––Koos
​
PS. In your previous email, something (your email client?) removed the
vertical line from the quoted Chris's email, so it looks like just an
indented block. I wonder if a setting could fix that.​


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add single() to itertools

[Greg Ewing]

(Reposting this to list -- pushed wrong reply button!)




Koos Zevenhoven
wrote:


  
  
  |defsingle(i): try: ||v =i.next()
|||exceptStopIteration:raiseException('No
values')|||try: ||i.next() ||exceptStopIteration: ||returnv||else:
||raiseException('Too many values')|||printsingle(name forname
in('bob','fred')ifname=='bob')||| |
  
  



  
  
   
  
  

Looks like a clever method of whitespace compression to me.
Those
narrow vertical bars take up far less room that spaces!








-- 
Greg







___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

[Petr Viktorin]

On 10/31/2017 09:54 AM, Koos Zevenhoven wrote:
On Tue, Oct 31, 2017 at 10:01 AM, Chris Angelico >wrote:


On Tue, Oct 31, 2017 at 6:46 PM, Steven D'Aprano
> wrote:
> On Tue, Oct 31, 2017 at 06:02:34PM +1100, Chris Angelico wrote:
>> One small change: If you use next(i) instead of i.next(), your code
>> should work on both Py2 and Py3. But other than that, I think it's
>> exactly the same as most people would expect of this function.
>
> Not me. As far as I can tell, that's semantically equivalent to:
>
> def single(i):
>     result, = i
>     return result
>
> apart from slightly different error messages.

I saw the original code as being like the itertools explanatory
functions - you wouldn't actually USE those functions, but they tell
you what's going on when you use the simpler, faster, more compact
form.


​I wonder if that's more easily understood if you write it along these 
line(s):


   (the_bob,) = ​(name for name in ('bob','fred') if name=='bob')


There are (unfortunately) several ways to do it. I prefer one that 
avoids a trailing comma:


[the_bob] = ​(name for name in ('bob','fred') if name=='bob')

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

[Koos Zevenhoven]

On Tue, Oct 31, 2017 at 10:01 AM, Chris Angelico  wrote:

> On Tue, Oct 31, 2017 at 6:46 PM, Steven D'Aprano 
> wrote:
> > On Tue, Oct 31, 2017 at 06:02:34PM +1100, Chris Angelico wrote:
> >> One small change: If you use next(i) instead of i.next(), your code
> >> should work on both Py2 and Py3. But other than that, I think it's
> >> exactly the same as most people would expect of this function.
> >
> > Not me. As far as I can tell, that's semantically equivalent to:
> >
> > def single(i):
> > result, = i
> > return result
> >
> > apart from slightly different error messages.
>
> I saw the original code as being like the itertools explanatory
> functions - you wouldn't actually USE those functions, but they tell
> you what's going on when you use the simpler, faster, more compact
> form.
>

​I wonder if that's more easily understood if you write it along these
line(s):

  (the_bob,) = ​(name for name in ('bob','fred') if name=='bob')

People need to learn about how to make a 1-tuple quite early on anyway, and
omitting the parentheses doesn't really help there, AFAICT. Then again, the
idiom looks even better when doing

  a, b = find_complex_roots(polynomial_of_second_order)

Except of course that I couldn't really come up with a good example of
something that is expected to find exactly two values from a larger
collection, and the students are already coming into the lecture hall.

Or should it be

  (a, b,) = find_complex_roots(polynomial_of_second_order)

?

––Koos


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

[Chris Angelico]

On Tue, Oct 31, 2017 at 6:46 PM, Steven D'Aprano  wrote:
> On Tue, Oct 31, 2017 at 06:02:34PM +1100, Chris Angelico wrote:
>> One small change: If you use next(i) instead of i.next(), your code
>> should work on both Py2 and Py3. But other than that, I think it's
>> exactly the same as most people would expect of this function.
>
> Not me. As far as I can tell, that's semantically equivalent to:
>
> def single(i):
> result, = i
> return result
>
> apart from slightly different error messages.

I saw the original code as being like the itertools explanatory
functions - you wouldn't actually USE those functions, but they tell
you what's going on when you use the simpler, faster, more compact
form.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add single() to itertools

[Koos Zevenhoven]

>
>
> |defsingle(i): try: ||v =i.next() 
> |||exceptStopIteration:raiseException('No
> values')|||try: ||i.next() ||exceptStopIteration: ||returnv||else:
> ||raiseException('Too many values')|
> ||printsingle(name forname in('bob','fred')ifname=='bob')||| |
>
>
​Now that looks seriously weird. Oh wait, I know, it must be a regular
expression! Perhaps mixed with Perl? To figure out what it does, we could
try compiling it and throwing input at it, or perhaps more simply by just
reverse engineering the implementation.

––Koos​
​​

-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

[Chris Angelico]

On Tue, Oct 31, 2017 at 5:18 PM, Ivan Pozdeev via Python-ideas
 wrote:
>> raise WhitespaceDamagedException from None
>
>
> Thunderbird jerked on me big time. It never did anything like this before!
> Switched off Digest mode, individual messages aren't so complicated.
>
> def single(i):
> try:
> v =i.next()
> except StopIteration:
> raise ValueError('No items')
> try:
> i.next()
> except StopIteration:
> return v
> else:
> raise ValueError('More than one item')
>
> print single(name for name in('bob','fred') if name=='bob')
>

Thanks :)

One small change: If you use next(i) instead of i.next(), your code
should work on both Py2 and Py3. But other than that, I think it's
exactly the same as most people would expect of this function.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Python-ideas Digest, Vol 131, Issue 106

[Ivan Pozdeev via Python-ideas]

On 31.10.2017 8:37, python-ideas-requ...@python.org wrote:
On Tue, Oct 31, 2017 at 3:50 PM, Ivan Pozdeev via Python-ideas 
 wrote:

On 30.10.2017 17:32, Guido van Rossum wrote:

This is a key example of a case where code speaks. Can you write an
implementation of how you would want single() to work in Python code?

On Mon, Oct 30, 2017 at 2:49 AM, Ivan Pozdeev via Python-ideas
> wrote:

 The initial post on the above link summarizes the suggested
 implementation pretty well.


|defsingle(i): try: ||v =i.next()
|||exceptStopIteration:raiseException('No values')|||try: ||i.next()
||exceptStopIteration: ||returnv||else: ||raiseException('Too many values')|
||printsingle(name forname in('bob','fred')ifname=='bob')||| |

||

raise WhitespaceDamagedException from None

ChrisA


Thunderbird jerked on me big time. It never did anything like this 
before! Switched off Digest mode, individual messages aren't so complicated.


def single(i):
    try:
    v =i.next()
    except StopIteration:
    raise ValueError('No items')
    try:
    i.next()
    except StopIteration:
    return v
    else:
    raise ValueError('More than one item')

print single(name for name in('bob','fred') if name=='bob')

--

Regards,
Ivan

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add processor generation to wheel metadata

[Nathaniel Smith]

On Mon, Oct 30, 2017 at 5:45 AM, Ivan Pozdeev via Python-ideas
 wrote:
> Generally, packages are compiled for the same processor generation as the
> corresponding Python.
> But not always -- e.g. NumPy opted for SSE2 even for Py2 to work around some
> compiler bug
> (https://github.com/numpy/numpy/issues/6428).
> I was bitten by that at an old machine once and found out that there is no
> way for `pip' to have checked for that.
> Besides, performance-oriented packages like the one mentioned could probably
> benefit from newer instructions.

You should probably resend this to distutils-sig instead of
python-ideas -- that's where discussions about python packaging
happen. (Python-ideas is more for discussions about the language
itself.)

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/