From ralf.gommers at gmail.com  Sat Sep  1 19:19:44 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 1 Sep 2018 16:19:44 -0700
Subject: [Numpy-discussion] Adoption of a Code of Conduct
In-Reply-To: <7fa6643ec8189e90f1600febf955d2244d696923.camel@sipsolutions.net>
References: <CACUQHuJx4JrCeiDir=uj_TzuMW9SORMieRZsXyz0fv-3yx+tLQ@mail.gmail.com>
 <CAB6mnxKyHaJVWo95_ioBrwPpDhmjBCzoskQ_jBvSDaqOxnccew@mail.gmail.com>
 <CABL7CQgZabCziD1qQUL534aQFwJJc5e=Gsyw7CsCr=wkXGBeOw@mail.gmail.com>
 <7fa6643ec8189e90f1600febf955d2244d696923.camel@sipsolutions.net>
Message-ID: <CABL7CQhK2zvZonATOQJm8eif==0drdHVzVt24V_NVtheyZ_f4w@mail.gmail.com>

On Wed, Aug 15, 2018 at 12:59 PM Sebastian Berg <sebastian at sipsolutions.net>
wrote:

> On Tue, 2018-08-14 at 21:30 -0700, Ralf Gommers wrote:
> >
> >
> > On Fri, Aug 3, 2018 at 1:02 PM, Charles R Harris <
> > charlesr.harris at gmail.com> wrote:
> > >
> > > On Fri, Aug 3, 2018 at 1:45 PM, Peter Creasey <
> > > p.e.creasey.00 at googlemail.com> wrote:
> > > > +1 for keeping the same CoC as Scipy, making a new thing just
> > > > seems a
> > > > bigger surface area to maintain. Personally I already assumed
> > > > Scipy's
> > > > "honour[ing] diversity in..." did not imply any protection of
> > > > behaviours that violate the CoC *itself*, but if you wanted to be
> > > > really explicit you could add "to the extent that these do not
> > > > conflict with this code of conduct." to that line.
> > >
> > > I prefer that to the proposed modification, short and sweet.
> > >
> >
> > This edit to the SciPy CoC has now been merged.
> >
> > It looks to me like we're good to go here and take over the SciPy
> > CoC.
>
>
> Sounds good, so +1.
>

Added in PR https://github.com/numpy/numpy/pull/11865.


> I am happy with the committee as well, and I guess most/all are, but we
> might want to discuss it separately?
>

I just included it in the PR, to get something up finally. If there's any
concerns about the commitee or if someone wants to volunteer to be on it,
let's discuss it here (or if someone is not comfortable with that, email me
or someone else on the Steering Council privately).

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180901/d7bd6149/attachment.html>

From ralf.gommers at gmail.com  Sun Sep  2 00:15:36 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 1 Sep 2018 21:15:36 -0700
Subject: [Numpy-discussion] rescuing missing data documents
Message-ID: <CABL7CQiYYYtFxCTBxFySkerWyxLPhNCFsZaFBYJiYTSy1TtGtA@mail.gmail.com>

Hi all,

Recently a few people (Tyler, Matti, myself, maybe others?) were discussing
the history of missing data in the context of custom dtypes. I mentioned
that there was a good write-up, but couldn't find it at the time. I just
stumbled across it, it's hidden in the numpy.org repo:
http://www.numpy.org/NA-overview. So hope this helps.

That document further references two alternative NEPs that didn't make it
into our repo:
1. https://gist.github.com/njsmith/1056379 (authors Matthew Brett,
Nathaniel Smith),
2. https://gist.github.com/njsmith/1068264 (author Nathaniel Smith),
as well as another summary:
https://github.com/njsmith/numpy/wiki/NA-discussion-status

I'd like to see the NEPs rescued, and the summary moved from the numpy.org
repo (maybe into yet another NEP?). It would be best if the original
authors do this, but otherwise I'm happy to do it. Thoughts?

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180901/b40fdc5f/attachment.html>

From stefanv at berkeley.edu  Sun Sep  2 04:15:29 2018
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Sun, 02 Sep 2018 10:15:29 +0200
Subject: [Numpy-discussion] rescuing missing data documents
In-Reply-To: <CABL7CQiYYYtFxCTBxFySkerWyxLPhNCFsZaFBYJiYTSy1TtGtA@mail.gmail.com>
References: <CABL7CQiYYYtFxCTBxFySkerWyxLPhNCFsZaFBYJiYTSy1TtGtA@mail.gmail.com>
Message-ID: <1659959e0e8.27ae.acf34a9c767d7bb498a799333be0433e@fastmail.com>

On September 2, 2018 06:16:36 Ralf Gommers <ralf.gommers at gmail.com> wrote:
> I'd like to see the NEPs rescued, and the summary moved from the numpy.org 
> repo (maybe into yet another NEP?). It would be best if the original 
> authors do this, but otherwise I'm happy to do it. Thoughts?

I think this is an excellent suggestion.  A lot of recollections like these 
live in various community members' heads only (some of them no longer 
involved), so I'd love to see that history more carefully reconstructed. 
And the longer we leave it, the harder the detective work becomes!

Best regards,
St?fan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180902/6c25215d/attachment.html>

From njs at pobox.com  Sun Sep  2 04:20:44 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Sun, 2 Sep 2018 01:20:44 -0700
Subject: [Numpy-discussion] rescuing missing data documents
In-Reply-To: <CABL7CQiYYYtFxCTBxFySkerWyxLPhNCFsZaFBYJiYTSy1TtGtA@mail.gmail.com>
References: <CABL7CQiYYYtFxCTBxFySkerWyxLPhNCFsZaFBYJiYTSy1TtGtA@mail.gmail.com>
Message-ID: <CAPJVwBmLvkg-O+L2VmkWZ6Z-DCcsnVSqJN5WVjC3H2aUwBpm7Q@mail.gmail.com>

Makes sense to me

On Sat, Sep 1, 2018 at 9:15 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> Hi all,
>
> Recently a few people (Tyler, Matti, myself, maybe others?) were discussing
> the history of missing data in the context of custom dtypes. I mentioned
> that there was a good write-up, but couldn't find it at the time. I just
> stumbled across it, it's hidden in the numpy.org repo:
> http://www.numpy.org/NA-overview. So hope this helps.
>
> That document further references two alternative NEPs that didn't make it
> into our repo:
> 1. https://gist.github.com/njsmith/1056379 (authors Matthew Brett, Nathaniel
> Smith),
> 2. https://gist.github.com/njsmith/1068264 (author Nathaniel Smith),
> as well as another summary:
> https://github.com/njsmith/numpy/wiki/NA-discussion-status
>
> I'd like to see the NEPs rescued, and the summary moved from the numpy.org
> repo (maybe into yet another NEP?). It would be best if the original authors
> do this, but otherwise I'm happy to do it. Thoughts?
>
> Cheers,
> Ralf
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>



-- 
Nathaniel J. Smith -- https://vorpus.org

From charlesr.harris at gmail.com  Sun Sep  2 14:58:50 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 2 Sep 2018 12:58:50 -0600
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
Message-ID: <CAB6mnxJB32raCJQuHDMKkm1kvzM+e_9Bge-KRP8NWFgQ_UqQ8Q@mail.gmail.com>

On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <shoyer at gmail.com> wrote:

> I propose to accept NEP-18, "A dispatch mechanism for NumPy?s high level
> array functions":
> http://www.numpy.org/neps/nep-0018-array-function-protocol.html
>
> Since the last round of discussion, we added a new section on "Callable
> objects generated at runtime" clarifying that to handle such objects is out
> of scope for the initial proposal in the NEP.
>
> If there are no substantive objections within 7 days from this email, then
> the NEP will be accepted; see NEP 0 for more details.
>
>
Skipping over all the discussion following this for brevity. I find myself
in general agreement with Stephan and think we should go ahead and merge
this. A few points:

   1. I don't think we should have an opt in environment variable, just put
   `__array_function__` out there with the understanding that it might change
   with experience. I don't think scores, let alone thousands, of folks are
   going to rush to take advantage of this, most likely the developers of the
   proposal will be the early adopters.
   2. I have a preference for implementing high level functions rather than
   low level, and fewer rather than more, with the choice driven by need. I
   think that will limit the amount of interdependence tangle and, in the long
   run, might serve to define an unofficial NumPy API.
   3. NumPy cannot manage all the projects that make use of the new option
   to keep them in sync, we have neither the time nor experience to do so, and
   historic attempts along those lines tended to die in obscurity. To the
   extent that we do so, it comes down to 2.
   4. I don't think this conflicts with Nathaniel's proposal, the main
   disagreement seems to over how to proceed and the selection of functions,
   see 2.
   5. The `__array_function_types__` idea looks interesting.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180902/80866523/attachment.html>

From charlesr.harris at gmail.com  Sun Sep  2 15:08:03 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 2 Sep 2018 13:08:03 -0600
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAB6mnxJB32raCJQuHDMKkm1kvzM+e_9Bge-KRP8NWFgQ_UqQ8Q@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnxJB32raCJQuHDMKkm1kvzM+e_9Bge-KRP8NWFgQ_UqQ8Q@mail.gmail.com>
Message-ID: <CAB6mnxKSbVJ8LU0-V66kQidwHR7z+eLrOQNhAv5dY=+u7tNNcQ@mail.gmail.com>

On Sun, Sep 2, 2018 at 12:58 PM Charles R Harris <charlesr.harris at gmail.com>
wrote:

>
>
> On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <shoyer at gmail.com> wrote:
>
>> I propose to accept NEP-18, "A dispatch mechanism for NumPy?s high level
>> array functions":
>> http://www.numpy.org/neps/nep-0018-array-function-protocol.html
>>
>> Since the last round of discussion, we added a new section on "Callable
>> objects generated at runtime" clarifying that to handle such objects is out
>> of scope for the initial proposal in the NEP.
>>
>> If there are no substantive objections within 7 days from this email,
>> then the NEP will be accepted; see NEP 0 for more details.
>>
>>
> Skipping over all the discussion following this for brevity. I find myself
> in general agreement with Stephan and think we should go ahead and merge
> this. A few points:
>
>    1. I don't think we should have an opt in environment variable, just
>    put `__array_function__` out there with the understanding that it might
>    change with experience. I don't think scores, let alone thousands, of folks
>    are going to rush to take advantage of this, most likely the developers of
>    the proposal will be the early adopters.
>    2. I have a preference for implementing high level functions rather
>    than low level, and fewer rather than more, with the choice driven by need.
>    I think that will limit the amount of interdependence tangle and, in the
>    long run, might serve to define an unofficial NumPy API.
>    3. NumPy cannot manage all the projects that make use of the new
>    option to keep them in sync, we have neither the time nor experience to do
>    so, and historic attempts along those lines tended to die in obscurity. To
>    the extent that we do so, it comes down to 2.
>    4. I don't think this conflicts with Nathaniel's proposal, the main
>    disagreement seems to over how to proceed and the selection of functions,
>    see 2.
>    5. The `__array_function_types__` idea looks interesting.
>
>
We might want to add an 'Experimental' status for NEPs, meaning accepted
but subject to modification.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180902/de02ec53/attachment.html>

From tyler.je.reddy at gmail.com  Wed Sep  5 18:15:14 2018
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Wed, 5 Sep 2018 15:15:14 -0700
Subject: [Numpy-discussion] ARMv8 / shippable addition to CI
Message-ID: <CAHPuU_aCz8YqiD4EonP6naw7e=p7+tSJHqOX70XQKe2FSPFi1A@mail.gmail.com>

Hi,

Stefan & Matti wanted me to check on the mailing list about about adding
ARMv8 (free / shippable service) to NumPy CI on github -- is anyone opposed
to that?

Only obvious drawback seems to be that the service sometimes seems a little
unreliable, not that this is new to us; guess we could just turn it off if
so.

The issue with progress: https://github.com/numpy/numpy/issues/11702

All NumPy tests pass (regular not --full suite anyway) on Python 2.7 / 3.7
in 9 minutes if we cache the Cython build:
https://app.shippable.com/github/tylerjereddy/numpy/runs/56/summary/console

If we move forward: I've been testing on a personal branch so that I didn't
have to act on behalf of NumPy officially--does someone on the steering
council want to set up an official NumPy shippable account & ask them for
access (I think I had to push a button / send an email for ARMv8
specifically).

I can open a PR to NumPy proper if this is generally +1 now.

Tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180905/714a2e9d/attachment.html>

From dpgrote at lbl.gov  Wed Sep  5 19:37:14 2018
From: dpgrote at lbl.gov (David Grote)
Date: Wed, 5 Sep 2018 16:37:14 -0700
Subject: [Numpy-discussion] Problem with libgfortran installed with pip
 install numpy
Message-ID: <CA+fvD_Ks_Gx1wqEiHi0bMzD27fJQE29dZUGpzWo5y3_=xE_OaQ@mail.gmail.com>

Hi - I have recently come across this problem. On my mac, I build a Fortran
code, producing a shared object, that I import into Python along with
numpy. This had been working fine until recently when I started seeing sag
faults deep inside the Fortran code, usually in Fortran print statements. I
tracked this down to a gfortran version issue.

I use the brew installation of Python and gcc (using the most recent
version, 8.2.0). gcc of course installs a version of libgfortran.dylib.
Doing a lsof of a running Python, I see that it finds that copy of
libgfortran, and also a copy that was downloaded with numpy
(/usr/local/lib/python3.7/site-packages/numpy/.dylibs/libgfortran.3.dylib).
Looking at numpy's copy of libgfortran, I see that it is version 4.9.0,
much older. Since my code is importing numpy first, the OS seems be using
numpy's version of libgfortran to link when importing my code. I know from
other experience that older versions of libgfortran are not compatible with
code compiled using a new version of gfortran and so therefore segfaults
happen.

If I download the numpy source and do python setup.py install, I don't have
this problem.

After this long description, my question is why is such an old version of
gcc used to build the distribution of numpy that gets installed from pypi?
gcc version 4.9.0 is from 2014. Can a newer version be used?
   Thanks!
       Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180905/9ac3994e/attachment.html>

From charlesr.harris at gmail.com  Wed Sep  5 20:00:30 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 5 Sep 2018 18:00:30 -0600
Subject: [Numpy-discussion] Problem with libgfortran installed with pip
 install numpy
In-Reply-To: <CA+fvD_Ks_Gx1wqEiHi0bMzD27fJQE29dZUGpzWo5y3_=xE_OaQ@mail.gmail.com>
References: <CA+fvD_Ks_Gx1wqEiHi0bMzD27fJQE29dZUGpzWo5y3_=xE_OaQ@mail.gmail.com>
Message-ID: <CAB6mnxL5xYx7B6ezcVKQt1Tt8tMNHR_H19a1FpZVTtBWYwz6ww@mail.gmail.com>

On Wed, Sep 5, 2018 at 5:38 PM David Grote <dpgrote at lbl.gov> wrote:

>
> Hi - I have recently come across this problem. On my mac, I build a
> Fortran code, producing a shared object, that I import into Python along
> with numpy. This had been working fine until recently when I started seeing
> sag faults deep inside the Fortran code, usually in Fortran print
> statements. I tracked this down to a gfortran version issue.
>
> I use the brew installation of Python and gcc (using the most recent
> version, 8.2.0). gcc of course installs a version of libgfortran.dylib.
> Doing a lsof of a running Python, I see that it finds that copy of
> libgfortran, and also a copy that was downloaded with numpy
> (/usr/local/lib/python3.7/site-packages/numpy/.dylibs/libgfortran.3.dylib).
> Looking at numpy's copy of libgfortran, I see that it is version 4.9.0,
> much older. Since my code is importing numpy first, the OS seems be using
> numpy's version of libgfortran to link when importing my code. I know from
> other experience that older versions of libgfortran are not compatible with
> code compiled using a new version of gfortran and so therefore segfaults
> happen.
>
> If I download the numpy source and do python setup.py install, I don't
> have this problem.
>
> After this long description, my question is why is such an old version of
> gcc used to build the distribution of numpy that gets installed from pypi?
> gcc version 4.9.0 is from 2014. Can a newer version be used?
>

The library came in with the use of OpenBLAS, I don't think there is a
fundamental reason that a newer version of gfortran couldn't be used, but I
have little experience with the Mac. Note that we have also given up on 32
bit Python on Mac for library related reasons. Matthew Brett would be the
guy to discuss this with.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180905/4f525d77/attachment.html>

From ralf.gommers at gmail.com  Wed Sep  5 20:58:55 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 5 Sep 2018 17:58:55 -0700
Subject: [Numpy-discussion] ARMv8 / shippable addition to CI
In-Reply-To: <CAHPuU_aCz8YqiD4EonP6naw7e=p7+tSJHqOX70XQKe2FSPFi1A@mail.gmail.com>
References: <CAHPuU_aCz8YqiD4EonP6naw7e=p7+tSJHqOX70XQKe2FSPFi1A@mail.gmail.com>
Message-ID: <CABL7CQjyYy+mBFk3Ztuy9R06w=dUpoQ9_pBe3CFNeLTgSMnWWg@mail.gmail.com>

On Wed, Sep 5, 2018 at 3:15 PM Tyler Reddy <tyler.je.reddy at gmail.com> wrote:

> Hi,
>
> Stefan & Matti wanted me to check on the mailing list about about adding
> ARMv8 (free / shippable service) to NumPy CI on github -- is anyone opposed
> to that?
>

sounds fine (and useful) to me.


>
> Only obvious drawback seems to be that the service sometimes seems a
> little unreliable, not that this is new to us; guess we could just turn it
> off if so.
>

makes sense

Ralf


>
> The issue with progress: https://github.com/numpy/numpy/issues/11702
>
> All NumPy tests pass (regular not --full suite anyway) on Python 2.7 / 3.7
> in 9 minutes if we cache the Cython build:
> https://app.shippable.com/github/tylerjereddy/numpy/runs/56/summary/console
>
> If we move forward: I've been testing on a personal branch so that I
> didn't have to act on behalf of NumPy officially--does someone on the
> steering council want to set up an official NumPy shippable account & ask
> them for access (I think I had to push a button / send an email for ARMv8
> specifically).
>
> I can open a PR to NumPy proper if this is generally +1 now.
>
> Tyler
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180905/09cb7867/attachment-0001.html>

From m.h.vankerkwijk at gmail.com  Wed Sep  5 21:11:34 2018
From: m.h.vankerkwijk at gmail.com (Marten van Kerkwijk)
Date: Wed, 5 Sep 2018 21:11:34 -0400
Subject: [Numpy-discussion] ARMv8 / shippable addition to CI
In-Reply-To: <CABL7CQjyYy+mBFk3Ztuy9R06w=dUpoQ9_pBe3CFNeLTgSMnWWg@mail.gmail.com>
References: <CAHPuU_aCz8YqiD4EonP6naw7e=p7+tSJHqOX70XQKe2FSPFi1A@mail.gmail.com>
 <CABL7CQjyYy+mBFk3Ztuy9R06w=dUpoQ9_pBe3CFNeLTgSMnWWg@mail.gmail.com>
Message-ID: <CAJNV+9t7x-3-JEtEFHZiV2Z-DHSK-yYtofw0vGC1U_fqrKpPog@mail.gmail.com>

Might make most sense as part of a cron job rather than on every PR.
-- Marten

On Wed, Sep 5, 2018 at 8:59 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Wed, Sep 5, 2018 at 3:15 PM Tyler Reddy <tyler.je.reddy at gmail.com>
> wrote:
>
>> Hi,
>>
>> Stefan & Matti wanted me to check on the mailing list about about adding
>> ARMv8 (free / shippable service) to NumPy CI on github -- is anyone opposed
>> to that?
>>
>
> sounds fine (and useful) to me.
>
>
>>
>> Only obvious drawback seems to be that the service sometimes seems a
>> little unreliable, not that this is new to us; guess we could just turn it
>> off if so.
>>
>
> makes sense
>
> Ralf
>
>
>>
>> The issue with progress: https://github.com/numpy/numpy/issues/11702
>>
>> All NumPy tests pass (regular not --full suite anyway) on Python 2.7 /
>> 3.7 in 9 minutes if we cache the Cython build:
>> https://app.shippable.com/github/tylerjereddy/numpy/runs/56/summary/console
>>
>> If we move forward: I've been testing on a personal branch so that I
>> didn't have to act on behalf of NumPy officially--does someone on the
>> steering council want to set up an official NumPy shippable account & ask
>> them for access (I think I had to push a button / send an email for ARMv8
>> specifically).
>>
>> I can open a PR to NumPy proper if this is generally +1 now.
>>
>> Tyler
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180905/bf7bbaad/attachment.html>

From nussbaum at uni-mainz.de  Thu Sep  6 06:19:04 2018
From: nussbaum at uni-mainz.de (=?UTF-8?Q?Andreas_Nu=C3=9Fbaumer?=)
Date: Thu, 6 Sep 2018 12:19:04 +0200
Subject: [Numpy-discussion] scaling of the covariance matrix in np.polyfit
Message-ID: <CANdXcwFGSJqCqU_mna2OC3hDFz=AVNxRs3krOTc5XcAAULQHqA@mail.gmail.com>

Hi,

as previously discussed on the mailing list
http://numpy-discussion.10968.n7.nabble.com/Inconsistent-results-for-the-covariance-matrix-between-scipy-optimize-curve-fit-and-numpy-polyfit-td45582.html
and listed in the issude https://github.com/numpy/numpy/issues/11196
there is no-standard factor to the scaling of the covariance matrix in
np.polyfit.  A while ago, I posted the pull request
https://github.com/numpy/numpy/pull/11197 that removes the
non-standard factor and introduces an option to give out the unscaled
covariance. After an inital review by Marten van Kerkwijk, the only
problem left was the question about the api. I have not heard back in
while and was wondering whether there is still interest in this PR.

Greetings
Andreas

From njs at pobox.com  Fri Sep  7 00:33:36 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 6 Sep 2018 21:33:36 -0700
Subject: [Numpy-discussion] A minor milestone
Message-ID: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>

Looking at https://pypistats.org/packages/numpy , it appears that
August 24 was the last day when numpy had more Python 2 downloads than
Python 3 downloads (maybe ever?).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From hans.dembinski at gmail.com  Fri Sep  7 04:19:57 2018
From: hans.dembinski at gmail.com (Hans Dembinski)
Date: Fri, 7 Sep 2018 10:19:57 +0200
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
References: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
Message-ID: <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>


> On 7. Sep 2018, at 06:33, Nathaniel Smith <njs at pobox.com> wrote:
> 
> Looking at https://pypistats.org/packages/numpy , it appears that
> August 24 was the last day when numpy had more Python 2 downloads than
> Python 3 downloads (maybe ever?).

Good news, it is about time.

Just out of curiosity, what happened after Jul 27, when the downloads doubled?



From njs at pobox.com  Fri Sep  7 04:28:40 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 7 Sep 2018 01:28:40 -0700
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>
References: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
 <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>
Message-ID: <CAPJVwBmpdkSpiNfX494p57aqiK5frpbiYaZ=_oD=Vmh9Dc4oQg@mail.gmail.com>

On Fri, Sep 7, 2018 at 1:19 AM, Hans Dembinski <hans.dembinski at gmail.com> wrote:
>
>> On 7. Sep 2018, at 06:33, Nathaniel Smith <njs at pobox.com> wrote:
>>
>> Looking at https://pypistats.org/packages/numpy , it appears that
>> August 24 was the last day when numpy had more Python 2 downloads than
>> Python 3 downloads (maybe ever?).
>
> Good news, it is about time.
>
> Just out of curiosity, what happened after Jul 27, when the downloads doubled?

It turns out the original version of the statistics aggregation
program crashed constantly and lost tons of data. Donald Stufft
rewrote it (using my library trio :-)), and deployed it on July 26:

  https://github.com/pypa/linehaul/issues/30

So the old download stats are artifactually low, and from July 26 the
stats are accurate.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From charlesr.harris at gmail.com  Fri Sep  7 21:33:41 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 7 Sep 2018 19:33:41 -0600
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <CAPJVwBmpdkSpiNfX494p57aqiK5frpbiYaZ=_oD=Vmh9Dc4oQg@mail.gmail.com>
References: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
 <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>
 <CAPJVwBmpdkSpiNfX494p57aqiK5frpbiYaZ=_oD=Vmh9Dc4oQg@mail.gmail.com>
Message-ID: <CAB6mnxKzUG+JVOLStOfGNcVoV4BjUZdd4_HU=rC-P=DS=bE6qg@mail.gmail.com>

On Fri, Sep 7, 2018 at 2:31 AM Nathaniel Smith <njs at pobox.com> wrote:

> On Fri, Sep 7, 2018 at 1:19 AM, Hans Dembinski <hans.dembinski at gmail.com>
> wrote:
> >
> >> On 7. Sep 2018, at 06:33, Nathaniel Smith <njs at pobox.com> wrote:
> >>
> >> Looking at https://pypistats.org/packages/numpy , it appears that
> >> August 24 was the last day when numpy had more Python 2 downloads than
> >> Python 3 downloads (maybe ever?).
> >
> > Good news, it is about time.
> >
> > Just out of curiosity, what happened after Jul 27, when the downloads
> doubled?
>
> It turns out the original version of the statistics aggregation
> program crashed constantly and lost tons of data. Donald Stufft
> rewrote it (using my library trio :-)), and deployed it on July 26:
>
>   https://github.com/pypa/linehaul/issues/30
>
> So the old download stats are artifactually low, and from July 26 the
> stats are accurate.
>
>
Thanks for the link. It would be nice to improve the Windows numbers, Linux
is still very dominant. I suppose that might be an artifact of the systems
used by developers as opposed to end users. It would be a different open
source world if Microsoft had always released their compilers for free and
kept them current with the evolving ISO specs.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180907/a56fbfb6/attachment.html>

From charlesr.harris at gmail.com  Fri Sep  7 21:55:29 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Fri, 7 Sep 2018 19:55:29 -0600
Subject: [Numpy-discussion] C99
Message-ID: <CAB6mnx++rd0aG9_i6oiNwYhwhq_Zsnpx71Yyc8zE_aobEMoDbA@mail.gmail.com>

Hi All,

I've a PR up converting travis testing to use C99
<https://github.com/numpy/numpy/pull/11905>. I suspect we may not want to
merge it for a while, but it does raise a couple of style questions that we
should probably settle up front. Namely:


   - Should we allow // style comments
   - Should we allow variable declarations after code

I am sure there are others to consider that haven't occurred to me. I
confess that I am not a big fan of allowing either, but am probably
prejudiced by early familiarity with C89 and long years working to that
spec.

Thoughts?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180907/b0bc2c1b/attachment.html>

From njs at pobox.com  Sat Sep  8 01:13:39 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Fri, 7 Sep 2018 22:13:39 -0700
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <CAB6mnxKzUG+JVOLStOfGNcVoV4BjUZdd4_HU=rC-P=DS=bE6qg@mail.gmail.com>
References: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
 <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>
 <CAPJVwBmpdkSpiNfX494p57aqiK5frpbiYaZ=_oD=Vmh9Dc4oQg@mail.gmail.com>
 <CAB6mnxKzUG+JVOLStOfGNcVoV4BjUZdd4_HU=rC-P=DS=bE6qg@mail.gmail.com>
Message-ID: <CAPJVwB=sNMuZC2nEP1TezzQKDUM7Pi_pdv_vpnjJX9xotEOhNA@mail.gmail.com>

On Fri, Sep 7, 2018 at 6:33 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> Thanks for the link. It would be nice to improve the Windows numbers, Linux
> is still very dominant. I suppose that might be an artifact of the systems
> used by developers as opposed to end users. It would be a different open
> source world if Microsoft had always released their compilers for free and
> kept them current with the evolving ISO specs.

Well, keep in mind also that it's counting installs, not users...
people destroy and reinstall Linux systems a *lot* more often than
they do Windows/macOS systems, what with clouds and containers and CI
systems and all. On my personal laptop I install numpy maybe once per
release, but on Travis I install it half a dozen times every day.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From andyfaff at gmail.com  Sat Sep  8 01:16:22 2018
From: andyfaff at gmail.com (Andrew Nelson)
Date: Sat, 8 Sep 2018 15:16:22 +1000
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <CAPJVwB=sNMuZC2nEP1TezzQKDUM7Pi_pdv_vpnjJX9xotEOhNA@mail.gmail.com>
References: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
 <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>
 <CAPJVwBmpdkSpiNfX494p57aqiK5frpbiYaZ=_oD=Vmh9Dc4oQg@mail.gmail.com>
 <CAB6mnxKzUG+JVOLStOfGNcVoV4BjUZdd4_HU=rC-P=DS=bE6qg@mail.gmail.com>
 <CAPJVwB=sNMuZC2nEP1TezzQKDUM7Pi_pdv_vpnjJX9xotEOhNA@mail.gmail.com>
Message-ID: <CAAbtOZef3rBDNzPEE6C+t1MYn0rg=dSGEkB_KK7OL5n-sjCJzA@mail.gmail.com>

>  but on Travis I install it half a dozen times every day.

Good point. I wonder if there's any way to take that into account when
considering whether to drop versions.

On Sat, 8 Sep 2018 at 15:14, Nathaniel Smith <njs at pobox.com> wrote:

> On Fri, Sep 7, 2018 at 6:33 PM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> > Thanks for the link. It would be nice to improve the Windows numbers,
> Linux
> > is still very dominant. I suppose that might be an artifact of the
> systems
> > used by developers as opposed to end users. It would be a different open
> > source world if Microsoft had always released their compilers for free
> and
> > kept them current with the evolving ISO specs.
>
> Well, keep in mind also that it's counting installs, not users...
> people destroy and reinstall Linux systems a *lot* more often than
> they do Windows/macOS systems, what with clouds and containers and CI
> systems and all. On my personal laptop I install numpy maybe once per
> release, but on Travis I install it half a dozen times every day.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>


-- 
_____________________________________
Dr. Andrew Nelson


_____________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180908/52fa1f31/attachment.html>

From wieser.eric+numpy at gmail.com  Sat Sep  8 02:01:49 2018
From: wieser.eric+numpy at gmail.com (Eric Wieser)
Date: Fri, 7 Sep 2018 23:01:49 -0700
Subject: [Numpy-discussion] C99
In-Reply-To: <CAB6mnx++rd0aG9_i6oiNwYhwhq_Zsnpx71Yyc8zE_aobEMoDbA@mail.gmail.com>
References: <CAB6mnx++rd0aG9_i6oiNwYhwhq_Zsnpx71Yyc8zE_aobEMoDbA@mail.gmail.com>
Message-ID: <CAL1kJvBWXExRd1dOuRgTBYCnVWtUCu1MCPohaPN6MbVC3r3fKw@mail.gmail.com>

Thanks for the first step on this!

Should we allow // style comments

I don?t think it matters too much. I think it might be a little messy to
have a mix of the two styles where // means ?post py3? and /* */ means
pre-py3 - but at the same time, I do slightly prefer the C++-style. For C
contributors coming from python, I?d expect that it feels more natural to
only have to put a comment marker at the start of the line. We could
convert the /**/-style to //-style with a tool, but it?s probably not worth
the churn or time.

Should we allow variable declarations after code

I?d be very strongly in favor of this - it makes it much easier to extract
helper functions if variables are declared as late as they can be - plus it
make it easier to reason about early returns not needing goto fail.

Related to this feature, I think allowing for(int i = 0; i < N; i++) is a
clear win.

Eric

On Fri, 7 Sep 2018 at 18:56 Charles R Harris charlesr.harris at gmail.com
<http://mailto:charlesr.harris at gmail.com> wrote:

Hi All,
>
> I've a PR up converting travis testing to use C99
> <https://github.com/numpy/numpy/pull/11905>. I suspect we may not want to
> merge it for a while, but it does raise a couple of style questions that we
> should probably settle up front. Namely:
>
>
>    - Should we allow // style comments
>    - Should we allow variable declarations after code
>
> I am sure there are others to consider that haven't occurred to me. I
> confess that I am not a big fan of allowing either, but am probably
> prejudiced by early familiarity with C89 and long years working to that
> spec.
>
> Thoughts?
>
> Chuck
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180907/7d4fe7c6/attachment-0001.html>

From charlesr.harris at gmail.com  Sat Sep  8 09:06:37 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sat, 8 Sep 2018 07:06:37 -0600
Subject: [Numpy-discussion] C99
In-Reply-To: <CAL1kJvBWXExRd1dOuRgTBYCnVWtUCu1MCPohaPN6MbVC3r3fKw@mail.gmail.com>
References: <CAB6mnx++rd0aG9_i6oiNwYhwhq_Zsnpx71Yyc8zE_aobEMoDbA@mail.gmail.com>
 <CAL1kJvBWXExRd1dOuRgTBYCnVWtUCu1MCPohaPN6MbVC3r3fKw@mail.gmail.com>
Message-ID: <CAB6mnxLy0JOO51ab_te9y8f4QgQcc=RyfwSM=HwWKCA6tYQ0kA@mail.gmail.com>

On Sat, Sep 8, 2018 at 12:02 AM Eric Wieser <wieser.eric+numpy at gmail.com>
wrote:

> Thanks for the first step on this!
>
> Should we allow // style comments
>
> I don?t think it matters too much. I think it might be a little messy to
> have a mix of the two styles where // means ?post py3? and /* */ means
> pre-py3 - but at the same time, I do slightly prefer the C++-style. For C
> contributors coming from python, I?d expect that it feels more natural to
> only have to put a comment marker at the start of the line. We could
> convert the /**/-style to //-style with a tool, but it?s probably not
> worth the churn or time.
>
> Should we allow variable declarations after code
>
> I?d be very strongly in favor of this - it makes it much easier to extract
> helper functions if variables are declared as late as they can be - plus it
> make it easier to reason about early returns not needing goto fail.
>
> Related to this feature, I think allowing for(int i = 0; i < N; i++) is a
> clear win.
>
> Eric
>

Thinking about this some more, a good argument for going to full C99 is
that outside code written in that style can be brought in without a lot of
work.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180908/69f0d790/attachment.html>

From charlesr.harris at gmail.com  Sat Sep  8 09:44:22 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sat, 8 Sep 2018 07:44:22 -0600
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <CAAbtOZef3rBDNzPEE6C+t1MYn0rg=dSGEkB_KK7OL5n-sjCJzA@mail.gmail.com>
References: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
 <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>
 <CAPJVwBmpdkSpiNfX494p57aqiK5frpbiYaZ=_oD=Vmh9Dc4oQg@mail.gmail.com>
 <CAB6mnxKzUG+JVOLStOfGNcVoV4BjUZdd4_HU=rC-P=DS=bE6qg@mail.gmail.com>
 <CAPJVwB=sNMuZC2nEP1TezzQKDUM7Pi_pdv_vpnjJX9xotEOhNA@mail.gmail.com>
 <CAAbtOZef3rBDNzPEE6C+t1MYn0rg=dSGEkB_KK7OL5n-sjCJzA@mail.gmail.com>
Message-ID: <CAB6mnxJhLhWic-pY_NCjhDnN6D9b9hcQorOuAH=abomTi0ERSw@mail.gmail.com>

On Fri, Sep 7, 2018 at 11:16 PM Andrew Nelson <andyfaff at gmail.com> wrote:

> >  but on Travis I install it half a dozen times every day.
>
> Good point. I wonder if there's any way to take that into account when
> considering whether to drop versions.
>
> On Sat, 8 Sep 2018 at 15:14, Nathaniel Smith <njs at pobox.com> wrote:
>
>> On Fri, Sep 7, 2018 at 6:33 PM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> > Thanks for the link. It would be nice to improve the Windows numbers,
>> Linux
>> > is still very dominant. I suppose that might be an artifact of the
>> systems
>> > used by developers as opposed to end users. It would be a different open
>> > source world if Microsoft had always released their compilers for free
>> and
>> > kept them current with the evolving ISO specs.
>>
>> Well, keep in mind also that it's counting installs, not users...
>> people destroy and reinstall Linux systems a *lot* more often than
>> they do Windows/macOS systems, what with clouds and containers and CI
>> systems and all. On my personal laptop I install numpy maybe once per
>> release, but on Travis I install it half a dozen times every day.
>>
>>
Would be interesting if the travisCI and appveyor downloads could be
separated out.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180908/88f458d3/attachment.html>

From ralf.gommers at gmail.com  Sat Sep  8 13:02:12 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 8 Sep 2018 10:02:12 -0700
Subject: [Numpy-discussion] C99
In-Reply-To: <CAB6mnxLy0JOO51ab_te9y8f4QgQcc=RyfwSM=HwWKCA6tYQ0kA@mail.gmail.com>
References: <CAB6mnx++rd0aG9_i6oiNwYhwhq_Zsnpx71Yyc8zE_aobEMoDbA@mail.gmail.com>
 <CAL1kJvBWXExRd1dOuRgTBYCnVWtUCu1MCPohaPN6MbVC3r3fKw@mail.gmail.com>
 <CAB6mnxLy0JOO51ab_te9y8f4QgQcc=RyfwSM=HwWKCA6tYQ0kA@mail.gmail.com>
Message-ID: <CABL7CQh2qw-XdQYQKmMKhr2v338ZbDPOgo72Cw72xY-VU=3Dmg@mail.gmail.com>

On Sat, Sep 8, 2018 at 6:07 AM Charles R Harris <charlesr.harris at gmail.com>
wrote:

>
>
> On Sat, Sep 8, 2018 at 12:02 AM Eric Wieser <wieser.eric+numpy at gmail.com>
> wrote:
>
>> Thanks for the first step on this!
>>
>> Should we allow // style comments
>>
>> I don?t think it matters too much. I think it might be a little messy to
>> have a mix of the two styles where // means ?post py3? and /* */ means
>> pre-py3 - but at the same time, I do slightly prefer the C++-style. For C
>> contributors coming from python, I?d expect that it feels more natural to
>> only have to put a comment marker at the start of the line. We could
>> convert the /**/-style to //-style with a tool, but it?s probably not
>> worth the churn or time.
>>
>> Should we allow variable declarations after code
>>
>> I?d be very strongly in favor of this - it makes it much easier to
>> extract helper functions if variables are declared as late as they can be -
>> plus it make it easier to reason about early returns not needing goto
>> fail.
>>
>> Related to this feature, I think allowing for(int i = 0; i < N; i++) is
>> a clear win.
>>
>> Eric
>>
>
> Thinking about this some more, a good argument for going to full C99 is
> that outside code written in that style can be brought in without a lot of
> work.
>

Agreed. And we already have the pocketfft PR to prove that.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180908/4315ff5a/attachment.html>

From chris.barker at noaa.gov  Sat Sep  8 14:02:51 2018
From: chris.barker at noaa.gov (Chris Barker)
Date: Sat, 8 Sep 2018 20:02:51 +0200
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <CAB6mnxJhLhWic-pY_NCjhDnN6D9b9hcQorOuAH=abomTi0ERSw@mail.gmail.com>
References: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
 <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>
 <CAPJVwBmpdkSpiNfX494p57aqiK5frpbiYaZ=_oD=Vmh9Dc4oQg@mail.gmail.com>
 <CAB6mnxKzUG+JVOLStOfGNcVoV4BjUZdd4_HU=rC-P=DS=bE6qg@mail.gmail.com>
 <CAPJVwB=sNMuZC2nEP1TezzQKDUM7Pi_pdv_vpnjJX9xotEOhNA@mail.gmail.com>
 <CAAbtOZef3rBDNzPEE6C+t1MYn0rg=dSGEkB_KK7OL5n-sjCJzA@mail.gmail.com>
 <CAB6mnxJhLhWic-pY_NCjhDnN6D9b9hcQorOuAH=abomTi0ERSw@mail.gmail.com>
Message-ID: <CALGmxEJY38QC-8GjF7KDZUtXYxAwcMKz+-y1hqc=ZZ9cQV3uQQ@mail.gmail.com>

There are probably a LOT of Windows users getting numpy from conda as well.

(I know my CI's and users do...)

It'd be nice if there was some way to track real usage!

-CHB


On Sat, Sep 8, 2018 at 3:44 PM, Charles R Harris <charlesr.harris at gmail.com>
wrote:

>
>
> On Fri, Sep 7, 2018 at 11:16 PM Andrew Nelson <andyfaff at gmail.com> wrote:
>
>> >  but on Travis I install it half a dozen times every day.
>>
>> Good point. I wonder if there's any way to take that into account when
>> considering whether to drop versions.
>>
>> On Sat, 8 Sep 2018 at 15:14, Nathaniel Smith <njs at pobox.com> wrote:
>>
>>> On Fri, Sep 7, 2018 at 6:33 PM, Charles R Harris
>>> <charlesr.harris at gmail.com> wrote:
>>> > Thanks for the link. It would be nice to improve the Windows numbers,
>>> Linux
>>> > is still very dominant. I suppose that might be an artifact of the
>>> systems
>>> > used by developers as opposed to end users. It would be a different
>>> open
>>> > source world if Microsoft had always released their compilers for free
>>> and
>>> > kept them current with the evolving ISO specs.
>>>
>>> Well, keep in mind also that it's counting installs, not users...
>>> people destroy and reinstall Linux systems a *lot* more often than
>>> they do Windows/macOS systems, what with clouds and containers and CI
>>> systems and all. On my personal laptop I install numpy maybe once per
>>> release, but on Travis I install it half a dozen times every day.
>>>
>>>
> Would be interesting if the travisCI and appveyor downloads could be
> separated out.
>
> Chuck
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>


-- 

Christopher Barker, Ph.D.
Oceanographer

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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180908/3ee655b0/attachment.html>

From charlesr.harris at gmail.com  Sat Sep  8 15:17:34 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sat, 8 Sep 2018 13:17:34 -0600
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <CALGmxEJY38QC-8GjF7KDZUtXYxAwcMKz+-y1hqc=ZZ9cQV3uQQ@mail.gmail.com>
References: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
 <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>
 <CAPJVwBmpdkSpiNfX494p57aqiK5frpbiYaZ=_oD=Vmh9Dc4oQg@mail.gmail.com>
 <CAB6mnxKzUG+JVOLStOfGNcVoV4BjUZdd4_HU=rC-P=DS=bE6qg@mail.gmail.com>
 <CAPJVwB=sNMuZC2nEP1TezzQKDUM7Pi_pdv_vpnjJX9xotEOhNA@mail.gmail.com>
 <CAAbtOZef3rBDNzPEE6C+t1MYn0rg=dSGEkB_KK7OL5n-sjCJzA@mail.gmail.com>
 <CAB6mnxJhLhWic-pY_NCjhDnN6D9b9hcQorOuAH=abomTi0ERSw@mail.gmail.com>
 <CALGmxEJY38QC-8GjF7KDZUtXYxAwcMKz+-y1hqc=ZZ9cQV3uQQ@mail.gmail.com>
Message-ID: <CAB6mnxKQdTxwG0AzvQuZYbJcw-W8PQuxN+y-kSocUMUTXxjuwA@mail.gmail.com>

On Sat, Sep 8, 2018 at 12:03 PM Chris Barker <chris.barker at noaa.gov> wrote:

> There are probably a LOT of Windows users getting numpy from conda as well.
>
> (I know my CI's and users do...)
>
> It'd be nice if there was some way to track real usage!
>

I wonder if the conda folks have some statistics?

<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180908/4c0845ed/attachment.html>

From charlesr.harris at gmail.com  Sat Sep  8 15:23:30 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sat, 8 Sep 2018 13:23:30 -0600
Subject: [Numpy-discussion] C99
In-Reply-To: <CABL7CQh2qw-XdQYQKmMKhr2v338ZbDPOgo72Cw72xY-VU=3Dmg@mail.gmail.com>
References: <CAB6mnx++rd0aG9_i6oiNwYhwhq_Zsnpx71Yyc8zE_aobEMoDbA@mail.gmail.com>
 <CAL1kJvBWXExRd1dOuRgTBYCnVWtUCu1MCPohaPN6MbVC3r3fKw@mail.gmail.com>
 <CAB6mnxLy0JOO51ab_te9y8f4QgQcc=RyfwSM=HwWKCA6tYQ0kA@mail.gmail.com>
 <CABL7CQh2qw-XdQYQKmMKhr2v338ZbDPOgo72Cw72xY-VU=3Dmg@mail.gmail.com>
Message-ID: <CAB6mnxKt1QTxrOg+UTtx_VgNGdvOceXeb+KYfgA19Du7rEQuqA@mail.gmail.com>

On Sat, Sep 8, 2018 at 11:02 AM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Sat, Sep 8, 2018 at 6:07 AM Charles R Harris <charlesr.harris at gmail.com>
> wrote:
>
>>
>>
>> On Sat, Sep 8, 2018 at 12:02 AM Eric Wieser <wieser.eric+numpy at gmail.com>
>> wrote:
>>
>>> Thanks for the first step on this!
>>>
>>> Should we allow // style comments
>>>
>>> I don?t think it matters too much. I think it might be a little messy to
>>> have a mix of the two styles where // means ?post py3? and /* */ means
>>> pre-py3 - but at the same time, I do slightly prefer the C++-style. For C
>>> contributors coming from python, I?d expect that it feels more natural to
>>> only have to put a comment marker at the start of the line. We could
>>> convert the /**/-style to //-style with a tool, but it?s probably not
>>> worth the churn or time.
>>>
>>> Should we allow variable declarations after code
>>>
>>> I?d be very strongly in favor of this - it makes it much easier to
>>> extract helper functions if variables are declared as late as they can be -
>>> plus it make it easier to reason about early returns not needing goto
>>> fail.
>>>
>>> Related to this feature, I think allowing for(int i = 0; i < N; i++) is
>>> a clear win.
>>>
>>> Eric
>>>
>>
>> Thinking about this some more, a good argument for going to full C99 is
>> that outside code written in that style can be brought in without a lot of
>> work.
>>
>
> Agreed. And we already have the pocketfft PR to prove that.
>

Hmm, maybe  C_STYLE_GUIDE.rst.txt should be an NEP?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180908/5f087433/attachment-0001.html>

From ralf.gommers at gmail.com  Sat Sep  8 15:51:58 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 8 Sep 2018 12:51:58 -0700
Subject: [Numpy-discussion] C99
In-Reply-To: <CAB6mnxKt1QTxrOg+UTtx_VgNGdvOceXeb+KYfgA19Du7rEQuqA@mail.gmail.com>
References: <CAB6mnx++rd0aG9_i6oiNwYhwhq_Zsnpx71Yyc8zE_aobEMoDbA@mail.gmail.com>
 <CAL1kJvBWXExRd1dOuRgTBYCnVWtUCu1MCPohaPN6MbVC3r3fKw@mail.gmail.com>
 <CAB6mnxLy0JOO51ab_te9y8f4QgQcc=RyfwSM=HwWKCA6tYQ0kA@mail.gmail.com>
 <CABL7CQh2qw-XdQYQKmMKhr2v338ZbDPOgo72Cw72xY-VU=3Dmg@mail.gmail.com>
 <CAB6mnxKt1QTxrOg+UTtx_VgNGdvOceXeb+KYfgA19Du7rEQuqA@mail.gmail.com>
Message-ID: <CABL7CQi7yKZZjdhr_tVQ=j0NcJyYCPJsFx_uB+YAUNsM4sxdxA@mail.gmail.com>

On Sat, Sep 8, 2018 at 12:24 PM Charles R Harris <charlesr.harris at gmail.com>
wrote:

>
>
> On Sat, Sep 8, 2018 at 11:02 AM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>>
>> On Sat, Sep 8, 2018 at 6:07 AM Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>>
>>> On Sat, Sep 8, 2018 at 12:02 AM Eric Wieser <wieser.eric+numpy at gmail.com>
>>> wrote:
>>>
>>>> Thanks for the first step on this!
>>>>
>>>> Should we allow // style comments
>>>>
>>>> I don?t think it matters too much. I think it might be a little messy
>>>> to have a mix of the two styles where // means ?post py3? and /* */
>>>> means pre-py3 - but at the same time, I do slightly prefer the C++-style.
>>>> For C contributors coming from python, I?d expect that it feels more
>>>> natural to only have to put a comment marker at the start of the line. We
>>>> could convert the /**/-style to //-style with a tool, but it?s
>>>> probably not worth the churn or time.
>>>>
>>>> Should we allow variable declarations after code
>>>>
>>>> I?d be very strongly in favor of this - it makes it much easier to
>>>> extract helper functions if variables are declared as late as they can be -
>>>> plus it make it easier to reason about early returns not needing goto
>>>> fail.
>>>>
>>>> Related to this feature, I think allowing for(int i = 0; i < N; i++)
>>>> is a clear win.
>>>>
>>>> Eric
>>>>
>>>
>>> Thinking about this some more, a good argument for going to full C99 is
>>> that outside code written in that style can be brought in without a lot of
>>> work.
>>>
>>
>> Agreed. And we already have the pocketfft PR to prove that.
>>
>
> Hmm, maybe  C_STYLE_GUIDE.rst.txt should be an NEP?
>

+1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180908/c7fca276/attachment.html>

From charlesr.harris at gmail.com  Sat Sep  8 22:11:44 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sat, 8 Sep 2018 20:11:44 -0600
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
Message-ID: <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>

On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <shoyer at gmail.com> wrote:

> I propose to accept NEP-18, "A dispatch mechanism for NumPy?s high level
> array functions":
> http://www.numpy.org/neps/nep-0018-array-function-protocol.html
>
> Since the last round of discussion, we added a new section on "Callable
> objects generated at runtime" clarifying that to handle such objects is out
> of scope for the initial proposal in the NEP.
>
> If there are no substantive objections within 7 days from this email, then
> the NEP will be accepted; see NEP 0 for more details.
>
>
I've merged the PR. What next?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180908/6ddb15ec/attachment.html>

From pav at iki.fi  Sun Sep  9 17:15:14 2018
From: pav at iki.fi (Pauli Virtanen)
Date: Sun, 09 Sep 2018 23:15:14 +0200
Subject: [Numpy-discussion] The http://planet.scipy.org/ site is down.
In-Reply-To: <1774e779bd31b5dcb750c25b1c023fce9dbf691f.camel@iki.fi>
References: <CAB6mnxJxua=+N-dCJTxouPozjg63qLpWt3MN-BqMAefCMYbwBw@mail.gmail.com>
 <af8a9cd9-0141-439b-b57b-2d366e29a3dd@normalesup.org>
 <CAD5ZxVyon3GiTCb1KWPRM85esh_oYs=9onHo0s8YzGepYON_-g@mail.gmail.com>
 <CA+WonSRTJZA-GCmmwyyxrwwH8r3LQ8+dJLuWb0cN1QTtKVDTGg@mail.gmail.com>
 <CABL7CQiuV3AwAaxDPbj6LTJ0oiwLRaHThRndFpajThO5C7Kn_w@mail.gmail.com>
 <1774e779bd31b5dcb750c25b1c023fce9dbf691f.camel@iki.fi>
Message-ID: <a72397ff02a1315303437d6f95285ab400dfdfb0.camel@iki.fi>

ti, 2018-08-21 kello 01:02 +0200, Pauli Virtanen kirjoitti:
[clip]
> Not volunteering to take this into completion, though.

Well, turns out otherwise:

https://planetscipy.netlify.com/

https://github.com/pv/staticplanet/

It's just a essentially stateless static site generator that can be put
in a cronjob anywhere, so it's simple to move if I get tired of dealing
with it.

I understand that if "planet CNAME planetscipy.netlify.com." is added
to the scipy.org DNS, it would work after pressing some button.

	Pauli






From pmhobson at gmail.com  Sun Sep  9 23:08:28 2018
From: pmhobson at gmail.com (Paul Hobson)
Date: Sun, 9 Sep 2018 20:08:28 -0700
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <CAB6mnxKQdTxwG0AzvQuZYbJcw-W8PQuxN+y-kSocUMUTXxjuwA@mail.gmail.com>
References: <CAPJVwBnvX2uKFb5gU2Hkf6NjMv8dPb6VaHyAUZiLpQY9M9BDpQ@mail.gmail.com>
 <E48D9D50-967F-435A-8937-B0FA491B228A@gmail.com>
 <CAPJVwBmpdkSpiNfX494p57aqiK5frpbiYaZ=_oD=Vmh9Dc4oQg@mail.gmail.com>
 <CAB6mnxKzUG+JVOLStOfGNcVoV4BjUZdd4_HU=rC-P=DS=bE6qg@mail.gmail.com>
 <CAPJVwB=sNMuZC2nEP1TezzQKDUM7Pi_pdv_vpnjJX9xotEOhNA@mail.gmail.com>
 <CAAbtOZef3rBDNzPEE6C+t1MYn0rg=dSGEkB_KK7OL5n-sjCJzA@mail.gmail.com>
 <CAB6mnxJhLhWic-pY_NCjhDnN6D9b9hcQorOuAH=abomTi0ERSw@mail.gmail.com>
 <CALGmxEJY38QC-8GjF7KDZUtXYxAwcMKz+-y1hqc=ZZ9cQV3uQQ@mail.gmail.com>
 <CAB6mnxKQdTxwG0AzvQuZYbJcw-W8PQuxN+y-kSocUMUTXxjuwA@mail.gmail.com>
Message-ID: <CADT3MEAP0G0xrZRzRz=qXNfYgobUJHGskSg5w9fDUj_0eEEKEw@mail.gmail.com>

In addition to this, at least half the Windows-using Python people in my
social circle of switched to Windows Subsystem for Linux, which is quite
good now. In include myself in this, and only use python from "Windows"
when I have to deal with Access or MS-SQL Server databases (probably 10% of
my workload, lately)
-paul

On Sat, Sep 8, 2018 at 12:18 PM Charles R Harris <charlesr.harris at gmail.com>
wrote:

>
>
> On Sat, Sep 8, 2018 at 12:03 PM Chris Barker <chris.barker at noaa.gov>
> wrote:
>
>> There are probably a LOT of Windows users getting numpy from conda as
>> well.
>>
>> (I know my CI's and users do...)
>>
>> It'd be nice if there was some way to track real usage!
>>
>
> I wonder if the conda folks have some statistics?
>
> <snip>
>
> Chuck
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180909/4a63118e/attachment.html>

From chris.barker at noaa.gov  Mon Sep 10 15:09:45 2018
From: chris.barker at noaa.gov (Chris Barker)
Date: Mon, 10 Sep 2018 21:09:45 +0200
Subject: [Numpy-discussion] A minor milestone
Message-ID: <CALGmxEJcDNU5s5N6N=xtT22Xg-5ZH6wp6Mj=kg6xeQ39kSLT0g@mail.gmail.com>

On Sat, Sep 8, 2018 at 9:17 PM, Charles R Harris <charlesr.harris at gmail.com>
wrote:

> There are probably a LOT of Windows users getting numpy from conda as well.
>>
>> I wonder if the conda folks have some statistics?
>

I'm sure there is a better way that I don't know, but anaconda.org does
post number of downloads of pacakges:

https://anaconda.org/search?q=+numpy



So you've got conda-forge, and anaconda (which I think is the "default"
channel for conda and Anaconda users) and even an Intel version -- that's a
lot.

But we have the CI problem -- conda-forge, for instance, uses CIs to build
packages that depend on numpy -- so a LOT of those are downloaded to build
other packages -- Im guessing that's why conda-forge has the most downloads
of numpy (by a factor of 4) I suspect end users actually use defaults'
numpy more.

You can also see downloads by file for a given channel:

https://anaconda.org/conda-forge/numpy/files?sort=ndownloads&sort_order=desc&version=1.15.1





Which shows that py3 Linux is the most popular -- but again, probably CIs
heavily influence that.

Close-ish second is Linux py2.7, but 3.6 has 1.3 times as many -- so as the
OP said -- py3 is seeing a lot of use!

Even stronger for os-x

I have no idea what conclusions to draw from any of this, but if someone
can find an API to get this data, we could do more.

And I think there's an issue with Windows and py2.7 -- it doesn't show up
at all (probably the whole openblas / old compiler issue). So we dont know
the stats for 2.7 vs 3.6 on Windows.

-CHB










> <snip>
>
> Chuck
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
>

-- 

Christopher Barker, Ph.D.
Oceanographer

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

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180910/ed382627/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 495385 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180910/ed382627/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139604 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180910/ed382627/attachment-0003.png>

From mrocklin at gmail.com  Mon Sep 10 15:18:19 2018
From: mrocklin at gmail.com (Matthew Rocklin)
Date: Mon, 10 Sep 2018 15:18:19 -0400
Subject: [Numpy-discussion] A minor milestone
In-Reply-To: <CALGmxEJcDNU5s5N6N=xtT22Xg-5ZH6wp6Mj=kg6xeQ39kSLT0g@mail.gmail.com>
References: <CALGmxEJcDNU5s5N6N=xtT22Xg-5ZH6wp6Mj=kg6xeQ39kSLT0g@mail.gmail.com>
Message-ID: <CAJ8oX-F==3pgR8C8pN+OoGNHK=CTgRJsJOGicw_TX=zFoJQcuw@mail.gmail.com>

> I wonder if the conda folks have some statistics?

Unfortunately there's nothing that's pushed out to the general public.
There has been movement in that direction though, but it's slow moving.
I'll ping Stan Seibert, who is generally a good contact for this.

On Mon, Sep 10, 2018 at 3:13 PM Chris Barker <chris.barker at noaa.gov> wrote:

> On Sat, Sep 8, 2018 at 9:17 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>> There are probably a LOT of Windows users getting numpy from conda as
>>> well.
>>>
>>> I wonder if the conda folks have some statistics?
>>
>
> I'm sure there is a better way that I don't know, but anaconda.org does
> post number of downloads of pacakges:
>
> https://anaconda.org/search?q=+numpy
>
>
>
> So you've got conda-forge, and anaconda (which I think is the "default"
> channel for conda and Anaconda users) and even an Intel version -- that's a
> lot.
>
> But we have the CI problem -- conda-forge, for instance, uses CIs to build
> packages that depend on numpy -- so a LOT of those are downloaded to build
> other packages -- Im guessing that's why conda-forge has the most downloads
> of numpy (by a factor of 4) I suspect end users actually use defaults'
> numpy more.
>
> You can also see downloads by file for a given channel:
>
>
> https://anaconda.org/conda-forge/numpy/files?sort=ndownloads&sort_order=desc&version=1.15.1
>
>
>
>
>
> Which shows that py3 Linux is the most popular -- but again, probably CIs
> heavily influence that.
>
> Close-ish second is Linux py2.7, but 3.6 has 1.3 times as many -- so as
> the OP said -- py3 is seeing a lot of use!
>
> Even stronger for os-x
>
> I have no idea what conclusions to draw from any of this, but if someone
> can find an API to get this data, we could do more.
>
> And I think there's an issue with Windows and py2.7 -- it doesn't show up
> at all (probably the whole openblas / old compiler issue). So we dont know
> the stats for 2.7 vs 3.6 on Windows.
>
> -CHB
>
>
>
>
>
>
>
>
>
>
>> <snip>
>>
>> Chuck
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R            (206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115       (206) 526-6317   main reception
>
> Chris.Barker at noaa.gov
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180910/98a7393c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 139604 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180910/98a7393c/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 495385 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180910/98a7393c/attachment-0003.png>

From ralf.gommers at gmail.com  Wed Sep 12 01:38:33 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 11 Sep 2018 22:38:33 -0700
Subject: [Numpy-discussion] The http://planet.scipy.org/ site is down.
In-Reply-To: <a72397ff02a1315303437d6f95285ab400dfdfb0.camel@iki.fi>
References: <CAB6mnxJxua=+N-dCJTxouPozjg63qLpWt3MN-BqMAefCMYbwBw@mail.gmail.com>
 <af8a9cd9-0141-439b-b57b-2d366e29a3dd@normalesup.org>
 <CAD5ZxVyon3GiTCb1KWPRM85esh_oYs=9onHo0s8YzGepYON_-g@mail.gmail.com>
 <CA+WonSRTJZA-GCmmwyyxrwwH8r3LQ8+dJLuWb0cN1QTtKVDTGg@mail.gmail.com>
 <CABL7CQiuV3AwAaxDPbj6LTJ0oiwLRaHThRndFpajThO5C7Kn_w@mail.gmail.com>
 <1774e779bd31b5dcb750c25b1c023fce9dbf691f.camel@iki.fi>
 <a72397ff02a1315303437d6f95285ab400dfdfb0.camel@iki.fi>
Message-ID: <CABL7CQhijz=2+_2W_ps0EVScNAg5t_Eo8AMSZ2ETgneb3ORZ0w@mail.gmail.com>

On Sun, Sep 9, 2018 at 2:16 PM Pauli Virtanen <pav at iki.fi> wrote:

> ti, 2018-08-21 kello 01:02 +0200, Pauli Virtanen kirjoitti:
> [clip]
> > Not volunteering to take this into completion, though.
>
> Well, turns out otherwise:
>

Awesome, thanks a lot Pauli!


> https://planetscipy.netlify.com/
>
> https://github.com/pv/staticplanet/
>
> It's just a essentially stateless static site generator that can be put
> in a cronjob anywhere, so it's simple to move if I get tired of dealing
> with it.
>
> I understand that if "planet CNAME planetscipy.netlify.com." is added
> to the scipy.org DNS, it would work after pressing some button.
>

The buttons were pressed; we can all go back to reading
https://planet.scipy.org/

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180911/6ba10c8f/attachment.html>

From einstein.edison at gmail.com  Wed Sep 12 13:20:21 2018
From: einstein.edison at gmail.com (Hameer Abbasi)
Date: Wed, 12 Sep 2018 19:20:21 +0200
Subject: [Numpy-discussion] ANN: PyData/Sparse 0.4.1
Message-ID: <c6df6ee8-2d99-40d2-a4d9-58f6f364b824@Canary>

=============================
Announcing PyData/Sparse 0.4.1
=============================

(Apologies for the cross-posting)

Hi everyone,

This is a performance, bug-fix and feature release. The changelog can be seen at https://sparse.pydata.org/en/latest/changelog.html

Highlights include:
Faux In-place operations
Mixed ndarray-sparse operations
Fill-values other than zero
Misc support for different functions

What?s PyData/Sparse?
???????????

PyData/Sparse is a an N-dimensional sparse array library. It?s compatible with NumPy and follows the ndarray interface as closely as possible. It depends on NumPy, SciPy and Numba.

Where can I find PyData/Sparse?
???????????????
The project is available on GitHub at https://github.com/pydata/sparse and is available on PyPI and conda-forge as ?sparse?. Documentation is hosted as https://sparse.pydata.org.

Best Regards,
Hameer Abbasi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/1ab1dfc3/attachment.html>

From charlesr.harris at gmail.com  Wed Sep 12 20:02:48 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 12 Sep 2018 18:02:48 -0600
Subject: [Numpy-discussion] CI Testing
Message-ID: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>

Hi All,

We might want to take a look at testing/building on AZURE
<https://azure.microsoft.com/en-us/services/devops/pipelines/?&OCID=AID736750_SEM_CmoL6wVZ>.
Probably worth exploring, although it is hard to find all information.
IIRC, we got an offer from Microsoft along these lines a couple of years
ago when we were looking to support MSVC.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/2f1ebb86/attachment.html>

From tyler.je.reddy at gmail.com  Wed Sep 12 20:14:47 2018
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Wed, 12 Sep 2018 17:14:47 -0700
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
Message-ID: <CAHPuU_YPWf9u6uegtxkRguoMMX=AoGmGSYi_H35Cpy4nGasn1A@mail.gmail.com>

Could initially try just adding some "bonus" jobs (that are useful / nice,
but we can't afford to add to current CI load) as a trial maybe, and if
the free version or a deal / offer on better services proves more expedient
than what we currently have then progressively migrate if / as appropriate.

Would also be cool to have native ppc64 arch in CI, but I checked briefly
with IBM and no such integration exists with github as far as the contact
knew.

On Wed, 12 Sep 2018 at 17:03, Charles R Harris <charlesr.harris at gmail.com>
wrote:

> Hi All,
>
> We might want to take a look at testing/building on AZURE
> <https://azure.microsoft.com/en-us/services/devops/pipelines/?&OCID=AID736750_SEM_CmoL6wVZ>.
> Probably worth exploring, although it is hard to find all information.
> IIRC, we got an offer from Microsoft along these lines a couple of years
> ago when we were looking to support MSVC.
>
> Chuck
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/b10981ae/attachment.html>

From sseibert at anaconda.com  Wed Sep 12 20:25:33 2018
From: sseibert at anaconda.com (Stanley Seibert)
Date: Wed, 12 Sep 2018 19:25:33 -0500
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
Message-ID: <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>

I just finished adding support to the Numba repo for Azure Pipelines:

https://github.com/numba/numba/pull/3303

The "free for open source" tier is 10 concurrent jobs that can run up to 60
minutes each (although the website says 30 minutes), and no limit on
minutes per month.  Like the other CI services, it uses YAML files to
define the build and test process.  I found the documentation of the YAML
pipeline spec to be large, but still missing a number of small details and
explanations about how features worked together.  That said, the build
performance is *significantly* better than Travis CI and AppVeyor for all 3
platforms, and the convenience of all major platforms going through one
service is very nice.  Despite not liking the UI quite as much as Travis
CI, I think Numba will likely switch completely over to Azure assuming the
free offering continues to be this good.

If you go beyond the free tier, you can connect self-managed build workers
to the same system, but the build agent is written in C#, so I'm not sure
how portable it is to ARM or PPC yet.

On Wed, Sep 12, 2018 at 7:02 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

> Hi All,
>
> We might want to take a look at testing/building on AZURE
> <https://azure.microsoft.com/en-us/services/devops/pipelines/?&OCID=AID736750_SEM_CmoL6wVZ>.
> Probably worth exploring, although it is hard to find all information.
> IIRC, we got an offer from Microsoft along these lines a couple of years
> ago when we were looking to support MSVC.
>
> Chuck
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/afc70c3e/attachment-0001.html>

From sseibert at anaconda.com  Wed Sep 12 20:29:35 2018
From: sseibert at anaconda.com (Stanley Seibert)
Date: Wed, 12 Sep 2018 19:29:35 -0500
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
Message-ID: <CADv3RKSPDiHZdEOFYa33aZy2yKxiqGF9_BNJfSEAWtJGEwYkEQ@mail.gmail.com>

Also, if anyone is curious what the CI interface looks like for the results
of a finished build, here's the Numba build from that PR:

https://dev.azure.com/numba/numba/_build/results?buildId=34&view=logs


On Wed, Sep 12, 2018 at 7:25 PM, Stanley Seibert <sseibert at anaconda.com>
wrote:

> I just finished adding support to the Numba repo for Azure Pipelines:
>
> https://github.com/numba/numba/pull/3303
>
> The "free for open source" tier is 10 concurrent jobs that can run up to
> 60 minutes each (although the website says 30 minutes), and no limit on
> minutes per month.  Like the other CI services, it uses YAML files to
> define the build and test process.  I found the documentation of the YAML
> pipeline spec to be large, but still missing a number of small details and
> explanations about how features worked together.  That said, the build
> performance is *significantly* better than Travis CI and AppVeyor for all 3
> platforms, and the convenience of all major platforms going through one
> service is very nice.  Despite not liking the UI quite as much as Travis
> CI, I think Numba will likely switch completely over to Azure assuming the
> free offering continues to be this good.
>
> If you go beyond the free tier, you can connect self-managed build workers
> to the same system, but the build agent is written in C#, so I'm not sure
> how portable it is to ARM or PPC yet.
>
> On Wed, Sep 12, 2018 at 7:02 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>> Hi All,
>>
>> We might want to take a look at testing/building on AZURE
>> <https://azure.microsoft.com/en-us/services/devops/pipelines/?&OCID=AID736750_SEM_CmoL6wVZ>.
>> Probably worth exploring, although it is hard to find all information.
>> IIRC, we got an offer from Microsoft along these lines a couple of years
>> ago when we were looking to support MSVC.
>>
>> Chuck
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/16a62275/attachment.html>

From charlesr.harris at gmail.com  Wed Sep 12 20:32:18 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 12 Sep 2018 18:32:18 -0600
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
Message-ID: <CAB6mnxL3jHwqgvE8nw2-iktbUHUjqL9DSe-Q+Jku03udwaV3Rg@mail.gmail.com>

On Wed, Sep 12, 2018 at 6:26 PM Stanley Seibert <sseibert at anaconda.com>
wrote:

> I just finished adding support to the Numba repo for Azure Pipelines:
>
> https://github.com/numba/numba/pull/3303
>
> The "free for open source" tier is 10 concurrent jobs that can run up to
> 60 minutes each (although the website says 30 minutes), and no limit on
> minutes per month.  Like the other CI services, it uses YAML files to
> define the build and test process.  I found the documentation of the YAML
> pipeline spec to be large, but still missing a number of small details and
> explanations about how features worked together.  That said, the build
> performance is *significantly* better than Travis CI and AppVeyor for all 3
> platforms, and the convenience of all major platforms going through one
> service is very nice.  Despite not liking the UI quite as much as Travis
> CI, I think Numba will likely switch completely over to Azure assuming the
> free offering continues to be this good.
>

Yeah, the pictures of the UI didn't look as nice, but then, it isn't what
we are used to.

>
> If you go beyond the free tier, you can connect self-managed build workers
> to the same system, but the build agent is written in C#, so I'm not sure
> how portable it is to ARM or PPC yet.
>

Did you sign up as open source? And if so, were you able to do so as an
organization?

>
> On Wed, Sep 12, 2018 at 7:02 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>> Hi All,
>>
>> We might want to take a look at testing/building on AZURE
>> <https://azure.microsoft.com/en-us/services/devops/pipelines/?&OCID=AID736750_SEM_CmoL6wVZ>.
>> Probably worth exploring, although it is hard to find all information.
>> IIRC, we got an offer from Microsoft along these lines a couple of years
>> ago when we were looking to support MSVC.
>>
>>
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/18a89d58/attachment.html>

From sseibert at anaconda.com  Wed Sep 12 21:29:47 2018
From: sseibert at anaconda.com (Stanley Seibert)
Date: Wed, 12 Sep 2018 20:29:47 -0500
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CAB6mnxL3jHwqgvE8nw2-iktbUHUjqL9DSe-Q+Jku03udwaV3Rg@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
 <CAB6mnxL3jHwqgvE8nw2-iktbUHUjqL9DSe-Q+Jku03udwaV3Rg@mail.gmail.com>
Message-ID: <CADv3RKSZ1ipW4-D_iVPna6G=5GkPx7R0C95NET4ag883maCsYQ@mail.gmail.com>

On Wed, Sep 12, 2018 at 7:32 PM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Wed, Sep 12, 2018 at 6:26 PM Stanley Seibert <sseibert at anaconda.com>
> wrote:
>
>> If you go beyond the free tier, you can connect self-managed build
>> workers to the same system, but the build agent is written in C#, so I'm
>> not sure how portable it is to ARM or PPC yet.
>>
>
> Did you sign up as open source? And if so, were you able to do so as an
> organization?
>

Yes, it was pretty straightforward.  They seem to be using the simplistic
definition of "public repository == open source", so there was no
verification step.  I was able to create a project associated with the
numba organization on Github.  It seems to still require that you have
Microsoft accounts, and manage permissions on those, rather than inheriting
the settings from your Github repositories.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/dace01b5/attachment.html>

From charlesr.harris at gmail.com  Wed Sep 12 22:37:59 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 12 Sep 2018 20:37:59 -0600
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CADv3RKSZ1ipW4-D_iVPna6G=5GkPx7R0C95NET4ag883maCsYQ@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
 <CAB6mnxL3jHwqgvE8nw2-iktbUHUjqL9DSe-Q+Jku03udwaV3Rg@mail.gmail.com>
 <CADv3RKSZ1ipW4-D_iVPna6G=5GkPx7R0C95NET4ag883maCsYQ@mail.gmail.com>
Message-ID: <CAB6mnxKaOqhLDE2s7d3kTTxB6u1A7YLz7wtUaD=FzEpyn-s=7Q@mail.gmail.com>

On Wed, Sep 12, 2018 at 7:30 PM Stanley Seibert <sseibert at anaconda.com>
wrote:

>
>
> On Wed, Sep 12, 2018 at 7:32 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>>
>> On Wed, Sep 12, 2018 at 6:26 PM Stanley Seibert <sseibert at anaconda.com>
>> wrote:
>>
>>> If you go beyond the free tier, you can connect self-managed build
>>> workers to the same system, but the build agent is written in C#, so I'm
>>> not sure how portable it is to ARM or PPC yet.
>>>
>>
>> Did you sign up as open source? And if so, were you able to do so as an
>> organization?
>>
>
> Yes, it was pretty straightforward.  They seem to be using the simplistic
> definition of "public repository == open source", so there was no
> verification step.  I was able to create a project associated with the
> numba organization on Github.  It seems to still require that you have
> Microsoft accounts, and manage permissions on those, rather than inheriting
> the settings from your Github repositories.
>

That might change now the MS is acquiring Github.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/675b8065/attachment-0001.html>

From allanhaldane at gmail.com  Wed Sep 12 23:18:00 2018
From: allanhaldane at gmail.com (Allan Haldane)
Date: Wed, 12 Sep 2018 23:18:00 -0400
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CAHPuU_YPWf9u6uegtxkRguoMMX=AoGmGSYi_H35Cpy4nGasn1A@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CAHPuU_YPWf9u6uegtxkRguoMMX=AoGmGSYi_H35Cpy4nGasn1A@mail.gmail.com>
Message-ID: <88ec1482-7239-50d6-b591-a02de2b76995@gmail.com>

On 09/12/2018 08:14 PM, Tyler Reddy wrote:
> Would also be cool to have native ppc64 arch in CI, but I checked 
> briefly with IBM and no such integration exists with github as far as 
> the contact knew.

Hi Tyler,

ppc64 CI is available through OSUOSL. Earlier this year I requested a 
ppc64be test server through them, for numpy use, see this email and the 
links therein:

https://mail.python.org/pipermail/numpy-discussion/2018-January/077570.html

At the time I didn't sign up for CI because my focus was the test 
server, but I think it is still very much an option to ask for CI if we 
want. I don't yet have the time to do it myself, but I think anyone 
interested could do it pretty easily.

Incidentally, the test server is still available to any numpy devs who 
need it, just ping me for access.

Cheers,
Allan

From tyler.je.reddy at gmail.com  Wed Sep 12 23:33:06 2018
From: tyler.je.reddy at gmail.com (Tyler Reddy)
Date: Wed, 12 Sep 2018 20:33:06 -0700
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <88ec1482-7239-50d6-b591-a02de2b76995@gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CAHPuU_YPWf9u6uegtxkRguoMMX=AoGmGSYi_H35Cpy4nGasn1A@mail.gmail.com>
 <88ec1482-7239-50d6-b591-a02de2b76995@gmail.com>
Message-ID: <CAHPuU_b3G-tTgu0-xdR4bGLP=BFYqT9zVy5g1HHVsGu10SS_Ng@mail.gmail.com>

Hi Allan,

That's pretty cool -- I should follow-up on the CI part of it!

Tyler

On Wed, 12 Sep 2018 at 20:18, Allan Haldane <allanhaldane at gmail.com> wrote:

> On 09/12/2018 08:14 PM, Tyler Reddy wrote:
> > Would also be cool to have native ppc64 arch in CI, but I checked
> > briefly with IBM and no such integration exists with github as far as
> > the contact knew.
>
> Hi Tyler,
>
> ppc64 CI is available through OSUOSL. Earlier this year I requested a
> ppc64be test server through them, for numpy use, see this email and the
> links therein:
>
> https://mail.python.org/pipermail/numpy-discussion/2018-January/077570.html
>
> At the time I didn't sign up for CI because my focus was the test
> server, but I think it is still very much an option to ask for CI if we
> want. I don't yet have the time to do it myself, but I think anyone
> interested could do it pretty easily.
>
> Incidentally, the test server is still available to any numpy devs who
> need it, just ping me for access.
>
> Cheers,
> Allan
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/9a8cb1ae/attachment.html>

From ralf.gommers at gmail.com  Thu Sep 13 01:18:17 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 12 Sep 2018 22:18:17 -0700
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CAHPuU_b3G-tTgu0-xdR4bGLP=BFYqT9zVy5g1HHVsGu10SS_Ng@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CAHPuU_YPWf9u6uegtxkRguoMMX=AoGmGSYi_H35Cpy4nGasn1A@mail.gmail.com>
 <88ec1482-7239-50d6-b591-a02de2b76995@gmail.com>
 <CAHPuU_b3G-tTgu0-xdR4bGLP=BFYqT9zVy5g1HHVsGu10SS_Ng@mail.gmail.com>
Message-ID: <CABL7CQhf5z1sOD+z1Szv5ESUrK+2UEMjcm-+6rLSS464Ri3NwQ@mail.gmail.com>

On Wed, Sep 12, 2018 at 8:33 PM Tyler Reddy <tyler.je.reddy at gmail.com>
wrote:

> Hi Allan,
>
> That's pretty cool -- I should follow-up on the CI part of it!
>

It's quite nice to have access to more exotic hardware, but I'd recommend
not to add anything to our CI setup that's not a fully hosted service that
we control via a simple config file plus clicking some buttons on a web
interface once. Custom code and server credentials/maintenance stuff should
be avoided - always becomes painful at some point.

Cheers,
Ralf


> Tyler
>
> On Wed, 12 Sep 2018 at 20:18, Allan Haldane <allanhaldane at gmail.com>
> wrote:
>
>> On 09/12/2018 08:14 PM, Tyler Reddy wrote:
>> > Would also be cool to have native ppc64 arch in CI, but I checked
>> > briefly with IBM and no such integration exists with github as far as
>> > the contact knew.
>>
>> Hi Tyler,
>>
>> ppc64 CI is available through OSUOSL. Earlier this year I requested a
>> ppc64be test server through them, for numpy use, see this email and the
>> links therein:
>>
>>
>> https://mail.python.org/pipermail/numpy-discussion/2018-January/077570.html
>>
>> At the time I didn't sign up for CI because my focus was the test
>> server, but I think it is still very much an option to ask for CI if we
>> want. I don't yet have the time to do it myself, but I think anyone
>> interested could do it pretty easily.
>>
>> Incidentally, the test server is still available to any numpy devs who
>> need it, just ping me for access.
>>
>> Cheers,
>> Allan
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/3e3d0d68/attachment.html>

From ralf.gommers at gmail.com  Thu Sep 13 01:20:12 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Wed, 12 Sep 2018 22:20:12 -0700
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CAHPuU_YPWf9u6uegtxkRguoMMX=AoGmGSYi_H35Cpy4nGasn1A@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CAHPuU_YPWf9u6uegtxkRguoMMX=AoGmGSYi_H35Cpy4nGasn1A@mail.gmail.com>
Message-ID: <CABL7CQiX4oLuK3N41cMhdqRjK9cPSigjw+jx=6XYRS6cdCYncQ@mail.gmail.com>

On Wed, Sep 12, 2018 at 5:15 PM Tyler Reddy <tyler.je.reddy at gmail.com>
wrote:

> Could initially try just adding some "bonus" jobs (that are useful / nice,
> but we can't afford to add to current CI load) as a trial maybe, and if
> the free version or a deal / offer on better services proves more
> expedient than what we currently have then progressively migrate if / as
> appropriate.
>

+1 to Azure Pipelines if someone wants to work on the config. Appveyor is
slowish. Not a major bottleneck for NumPy (yet), but for SciPy it is -
often takes 2-4 hours for a build to complete.

Ralf


> Would also be cool to have native ppc64 arch in CI, but I checked briefly
> with IBM and no such integration exists with github as far as the contact
> knew.
>
> On Wed, 12 Sep 2018 at 17:03, Charles R Harris <charlesr.harris at gmail.com>
> wrote:
>
>> Hi All,
>>
>> We might want to take a look at testing/building on AZURE
>> <https://azure.microsoft.com/en-us/services/devops/pipelines/?&OCID=AID736750_SEM_CmoL6wVZ>.
>> Probably worth exploring, although it is hard to find all information.
>> IIRC, we got an offer from Microsoft along these lines a couple of years
>> ago when we were looking to support MSVC.
>>
>> Chuck
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180912/6a9aa75e/attachment-0001.html>

From charlesr.harris at gmail.com  Thu Sep 13 09:13:48 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 13 Sep 2018 07:13:48 -0600
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CADv3RKSZ1ipW4-D_iVPna6G=5GkPx7R0C95NET4ag883maCsYQ@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
 <CAB6mnxL3jHwqgvE8nw2-iktbUHUjqL9DSe-Q+Jku03udwaV3Rg@mail.gmail.com>
 <CADv3RKSZ1ipW4-D_iVPna6G=5GkPx7R0C95NET4ag883maCsYQ@mail.gmail.com>
Message-ID: <CAB6mnx+5SC30+kZP7P8PxseerbrAX=8xFROOZsZoALOGvVWVmA@mail.gmail.com>

On Wed, Sep 12, 2018 at 7:30 PM Stanley Seibert <sseibert at anaconda.com>
wrote:

>
>
> On Wed, Sep 12, 2018 at 7:32 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>>
>> On Wed, Sep 12, 2018 at 6:26 PM Stanley Seibert <sseibert at anaconda.com>
>> wrote:
>>
>>> If you go beyond the free tier, you can connect self-managed build
>>> workers to the same system, but the build agent is written in C#, so I'm
>>> not sure how portable it is to ARM or PPC yet.
>>>
>>
>> Did you sign up as open source? And if so, were you able to do so as an
>> organization?
>>
>
> Yes, it was pretty straightforward.  They seem to be using the simplistic
> definition of "public repository == open source", so there was no
> verification step.  I was able to create a project associated with the
> numba organization on Github.  It seems to still require that you have
> Microsoft accounts, and manage permissions on those, rather than inheriting
> the settings from your Github repositories.
>

So is the account set up in your name? What do you mean "manage
permissions", did you need to add names to the account via Microsoft and
does everyone accessing the account need to have a Microsoft account? It
would be helpful if you could go through the procedure step-by-step.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180913/118a91b6/attachment.html>

From sseibert at anaconda.com  Thu Sep 13 10:25:09 2018
From: sseibert at anaconda.com (Stanley Seibert)
Date: Thu, 13 Sep 2018 09:25:09 -0500
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CAB6mnx+5SC30+kZP7P8PxseerbrAX=8xFROOZsZoALOGvVWVmA@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
 <CAB6mnxL3jHwqgvE8nw2-iktbUHUjqL9DSe-Q+Jku03udwaV3Rg@mail.gmail.com>
 <CADv3RKSZ1ipW4-D_iVPna6G=5GkPx7R0C95NET4ag883maCsYQ@mail.gmail.com>
 <CAB6mnx+5SC30+kZP7P8PxseerbrAX=8xFROOZsZoALOGvVWVmA@mail.gmail.com>
Message-ID: <CADv3RKSJxuiEYwdER642rB_xJw4Ohb73Zz--1JL_F=241arjUA@mail.gmail.com>

I'm still trying to wrap my head around the security model here.  The
onboarding wizard makes it pretty easy to get started, but the UI
afterwards has a lot of complexity for managing fine grained permissions.
As I understand it, I made a "numba" project with my Microsoft account, but
I can add other Microsoft accounts to the project and give them varying
access to administer the project.  None of these user accounts or
permissions connect directly to Github accounts, so that is annoying if you
have a large core dev team you want to give permission to manage builds.
They will all need Microsoft accounts, and you will have to grant them
admin access to the project.  (Still trying to figure out how to do that
for Numba...)

Azure Pipeline's connection to Github itself (to post CI status under PRs,
etc) can be done either by granting permission via a Github user's account,
or by installing it as an "app" in the Github organization, which is the
route I opted for.

On Thu, Sep 13, 2018 at 8:13 AM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Wed, Sep 12, 2018 at 7:30 PM Stanley Seibert <sseibert at anaconda.com>
> wrote:
>
>>
>>
>> On Wed, Sep 12, 2018 at 7:32 PM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Sep 12, 2018 at 6:26 PM Stanley Seibert <sseibert at anaconda.com>
>>> wrote:
>>>
>>>> If you go beyond the free tier, you can connect self-managed build
>>>> workers to the same system, but the build agent is written in C#, so I'm
>>>> not sure how portable it is to ARM or PPC yet.
>>>>
>>>
>>> Did you sign up as open source? And if so, were you able to do so as an
>>> organization?
>>>
>>
>> Yes, it was pretty straightforward.  They seem to be using the simplistic
>> definition of "public repository == open source", so there was no
>> verification step.  I was able to create a project associated with the
>> numba organization on Github.  It seems to still require that you have
>> Microsoft accounts, and manage permissions on those, rather than inheriting
>> the settings from your Github repositories.
>>
>
> So is the account set up in your name? What do you mean "manage
> permissions", did you need to add names to the account via Microsoft and
> does everyone accessing the account need to have a Microsoft account? It
> would be helpful if you could go through the procedure step-by-step.
>
> Chuck
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180913/9236c132/attachment.html>

From sseibert at anaconda.com  Thu Sep 13 10:29:38 2018
From: sseibert at anaconda.com (Stanley Seibert)
Date: Thu, 13 Sep 2018 09:29:38 -0500
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CADv3RKSJxuiEYwdER642rB_xJw4Ohb73Zz--1JL_F=241arjUA@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
 <CAB6mnxL3jHwqgvE8nw2-iktbUHUjqL9DSe-Q+Jku03udwaV3Rg@mail.gmail.com>
 <CADv3RKSZ1ipW4-D_iVPna6G=5GkPx7R0C95NET4ag883maCsYQ@mail.gmail.com>
 <CAB6mnx+5SC30+kZP7P8PxseerbrAX=8xFROOZsZoALOGvVWVmA@mail.gmail.com>
 <CADv3RKSJxuiEYwdER642rB_xJw4Ohb73Zz--1JL_F=241arjUA@mail.gmail.com>
Message-ID: <CADv3RKRfKArPQDHM0sSY9W8+LECp5SHGfav1dTmx_fXX1Ts_4A@mail.gmail.com>

Another minor annoyance is that the link on the Github "Checks" page that
says "View More Details on Azure Pipelines" takes you to a login page,
which then forwards you to the public (no login required) pipeline build
results page.  As a result, people might not realize you can view the build
results for public projects without a Microsoft account, so you'll probably
want to put a build status badge with a direct link somewhere prominent in
the README.

On Thu, Sep 13, 2018 at 9:25 AM, Stanley Seibert <sseibert at anaconda.com>
wrote:

> I'm still trying to wrap my head around the security model here.  The
> onboarding wizard makes it pretty easy to get started, but the UI
> afterwards has a lot of complexity for managing fine grained permissions.
> As I understand it, I made a "numba" project with my Microsoft account, but
> I can add other Microsoft accounts to the project and give them varying
> access to administer the project.  None of these user accounts or
> permissions connect directly to Github accounts, so that is annoying if you
> have a large core dev team you want to give permission to manage builds.
> They will all need Microsoft accounts, and you will have to grant them
> admin access to the project.  (Still trying to figure out how to do that
> for Numba...)
>
> Azure Pipeline's connection to Github itself (to post CI status under PRs,
> etc) can be done either by granting permission via a Github user's account,
> or by installing it as an "app" in the Github organization, which is the
> route I opted for.
>
> On Thu, Sep 13, 2018 at 8:13 AM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>>
>> On Wed, Sep 12, 2018 at 7:30 PM Stanley Seibert <sseibert at anaconda.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Sep 12, 2018 at 7:32 PM, Charles R Harris <
>>> charlesr.harris at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 12, 2018 at 6:26 PM Stanley Seibert <sseibert at anaconda.com>
>>>> wrote:
>>>>
>>>>> If you go beyond the free tier, you can connect self-managed build
>>>>> workers to the same system, but the build agent is written in C#, so I'm
>>>>> not sure how portable it is to ARM or PPC yet.
>>>>>
>>>>
>>>> Did you sign up as open source? And if so, were you able to do so as an
>>>> organization?
>>>>
>>>
>>> Yes, it was pretty straightforward.  They seem to be using the
>>> simplistic definition of "public repository == open source", so there was
>>> no verification step.  I was able to create a project associated with the
>>> numba organization on Github.  It seems to still require that you have
>>> Microsoft accounts, and manage permissions on those, rather than inheriting
>>> the settings from your Github repositories.
>>>
>>
>> So is the account set up in your name? What do you mean "manage
>> permissions", did you need to add names to the account via Microsoft and
>> does everyone accessing the account need to have a Microsoft account? It
>> would be helpful if you could go through the procedure step-by-step.
>>
>> Chuck
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180913/34c73950/attachment-0001.html>

From charlesr.harris at gmail.com  Thu Sep 13 10:48:55 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 13 Sep 2018 08:48:55 -0600
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CADv3RKRfKArPQDHM0sSY9W8+LECp5SHGfav1dTmx_fXX1Ts_4A@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
 <CAB6mnxL3jHwqgvE8nw2-iktbUHUjqL9DSe-Q+Jku03udwaV3Rg@mail.gmail.com>
 <CADv3RKSZ1ipW4-D_iVPna6G=5GkPx7R0C95NET4ag883maCsYQ@mail.gmail.com>
 <CAB6mnx+5SC30+kZP7P8PxseerbrAX=8xFROOZsZoALOGvVWVmA@mail.gmail.com>
 <CADv3RKSJxuiEYwdER642rB_xJw4Ohb73Zz--1JL_F=241arjUA@mail.gmail.com>
 <CADv3RKRfKArPQDHM0sSY9W8+LECp5SHGfav1dTmx_fXX1Ts_4A@mail.gmail.com>
Message-ID: <CAB6mnx+9C58PvZgciFk4mf=2dLnwZTyKLvYFEwXbrnBKqyRNeg@mail.gmail.com>

On Thu, Sep 13, 2018 at 8:30 AM Stanley Seibert <sseibert at anaconda.com>
wrote:

> Another minor annoyance is that the link on the Github "Checks" page that
> says "View More Details on Azure Pipelines" takes you to a login page,
> which then forwards you to the public (no login required) pipeline build
> results page.  As a result, people might not realize you can view the build
> results for public projects without a Microsoft account, so you'll probably
> want to put a build status badge with a direct link somewhere prominent in
> the README.
>
> On Thu, Sep 13, 2018 at 9:25 AM, Stanley Seibert <sseibert at anaconda.com>
> wrote:
>
>> I'm still trying to wrap my head around the security model here.  The
>> onboarding wizard makes it pretty easy to get started, but the UI
>> afterwards has a lot of complexity for managing fine grained permissions.
>> As I understand it, I made a "numba" project with my Microsoft account, but
>> I can add other Microsoft accounts to the project and give them varying
>> access to administer the project.  None of these user accounts or
>> permissions connect directly to Github accounts, so that is annoying if you
>> have a large core dev team you want to give permission to manage builds.
>> They will all need Microsoft accounts, and you will have to grant them
>> admin access to the project.  (Still trying to figure out how to do that
>> for Numba...)
>>
>> Azure Pipeline's connection to Github itself (to post CI status under
>> PRs, etc) can be done either by granting permission via a Github user's
>> account, or by installing it as an "app" in the Github organization, which
>> is the route I opted for.
>>
>
Does Azure Pipeline respond to the Github hooks? We have hooks for all the
other testing sites.

Thanks for the continuing updates, you are one of the first explorers and
anything you can report back is of great help to the rest of us.


>> On Thu, Sep 13, 2018 at 8:13 AM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Sep 12, 2018 at 7:30 PM Stanley Seibert <sseibert at anaconda.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Sep 12, 2018 at 7:32 PM, Charles R Harris <
>>>> charlesr.harris at gmail.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Sep 12, 2018 at 6:26 PM Stanley Seibert <sseibert at anaconda.com>
>>>>> wrote:
>>>>>
>>>>>> If you go beyond the free tier, you can connect self-managed build
>>>>>> workers to the same system, but the build agent is written in C#, so I'm
>>>>>> not sure how portable it is to ARM or PPC yet.
>>>>>>
>>>>>
>>>>> Did you sign up as open source? And if so, were you able to do so as
>>>>> an organization?
>>>>>
>>>>
>>>> Yes, it was pretty straightforward.  They seem to be using the
>>>> simplistic definition of "public repository == open source", so there was
>>>> no verification step.  I was able to create a project associated with the
>>>> numba organization on Github.  It seems to still require that you have
>>>> Microsoft accounts, and manage permissions on those, rather than inheriting
>>>> the settings from your Github repositories.
>>>>
>>>
>>> So is the account set up in your name? What do you mean "manage
>>> permissions", did you need to add names to the account via Microsoft and
>>> does everyone accessing the account need to have a Microsoft account? It
>>> would be helpful if you could go through the procedure step-by-step.
>>>
>>>
Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180913/d8f1423a/attachment.html>

From shoyer at gmail.com  Thu Sep 13 13:30:20 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Thu, 13 Sep 2018 10:30:20 -0700
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
Message-ID: <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>

On Sat, Sep 8, 2018 at 7:12 PM Charles R Harris <charlesr.harris at gmail.com>
wrote:

> On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <shoyer at gmail.com> wrote:
>
>> I propose to accept NEP-18, "A dispatch mechanism for NumPy?s high level
>> array functions":
>> http://www.numpy.org/neps/nep-0018-array-function-protocol.html
>>
>> Since the last round of discussion, we added a new section on "Callable
>> objects generated at runtime" clarifying that to handle such objects is out
>> of scope for the initial proposal in the NEP.
>>
>> If there are no substantive objections within 7 days from this email,
>> then the NEP will be accepted; see NEP 0 for more details.
>>
>>
> I've merged the PR. What next?
>
> Chuck
>

I rolled back Chuck's merge of the "Acceptance" PR for this NEP because (1)
it was not clear that if had reached consensus and (2) I still wanted to
make a few changes based on this discussion.

I have now drafted these revisions to the NEP to clarify its stance around
backwards compatibility, and the type of the "types" argument:
https://github.com/numpy/numpy/pull/11943

I have *not* included any form of the explicit "end-user opt-in" requested
by Nathaniel. I don't think it is warranted based on the scope of
anticipated future changes; see my earlier post [1] for details. Nobody has
seriously suggested that we would release this functionality and later
eliminate the ability to override NumPy functions entirely in the future.

Of course, requiring an onerous explicit opt-in would be fine while this
feature is initially under development, and until we are sure that checks
for overriding arbitrary NumPy functions are fast enough to be generally
viable. In particular, we should verify that __array_function__ does not
meaningfully impact performance for major downstream components of the
SciPy stack. But I think running standard benchmark suites (e.g., with ASV)
and user testing of release candidates would be enough.

If you have still have major objections to this version of proposal, please
raise them unambiguously -- preferably with an formal veto [2].

Best,
Stephan

[1]
https://mail.python.org/pipermail/numpy-discussion/2018-August/078669.html
[2] https://docs.scipy.org/doc/numpy/dev/governance/governance.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180913/475aa71c/attachment.html>

From m.h.vankerkwijk at gmail.com  Thu Sep 13 14:41:15 2018
From: m.h.vankerkwijk at gmail.com (Marten van Kerkwijk)
Date: Thu, 13 Sep 2018 14:41:15 -0400
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
 <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
Message-ID: <CAJNV+9viwG+4ac--k1E-TDtnFFy+s12R_vDr_4kHF2GOp0dzRA@mail.gmail.com>

Thanks for adding the clarifications. They read well to me, and I think
make clear to a project like astropy what to expect (and I expect we'll be
use it!).  -- Marten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180913/5e64097e/attachment.html>

From einstein.edison at gmail.com  Thu Sep 13 14:50:28 2018
From: einstein.edison at gmail.com (Hameer Abbasi)
Date: Thu, 13 Sep 2018 20:50:28 +0200
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
 <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
Message-ID: <59d32e0e-7655-4d4a-9653-648687b5edc9@Canary>

> On Thursday, Sep 13, 2018 at 7:30 PM, Stephan Hoyer <shoyer at gmail.com (mailto:shoyer at gmail.com)> wrote:
>
>
> On Sat, Sep 8, 2018 at 7:12 PM Charles R Harris <charlesr.harris at gmail.com (mailto:charlesr.harris at gmail.com)> wrote:
>
>
>
>
> > On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <shoyer at gmail.com (mailto:shoyer at gmail.com)> wrote:
> >
> >
>
>
>
>
>
>
> > > I propose to accept NEP-18, "A dispatch mechanism for NumPy?s high level array functions":
> >
> >
> >
>
>
>
>
>
>
> > > http://www.numpy.org/neps/nep-0018-array-function-protocol.html
> > >
> >
> >
> >
>
>
>
>
> > >
> > > Since the last round of discussion, we added a new section on "Callable objects generated at runtime" clarifying that to handle such objects is out of scope for the initial proposal in the NEP.
> > >
> > > If there are no substantive objections within 7 days from this email, then the NEP will be accepted; see NEP 0 for more details.
> > >
> >
> > I've merged the PR. What next?
> >
> > Chuck
>
> I rolled back Chuck's merge of the "Acceptance" PR for this NEP because (1) it was not clear that if had reached consensus and (2) I still wanted to make a few changes based on this discussion.
>
> I have now drafted these revisions to the NEP to clarify its stance around backwards compatibility, and the type of the "types" argument: https://github.com/numpy/numpy/pull/11943
>
>
>
>
> I have *not* included any form of the explicit "end-user opt-in" requested by Nathaniel. I don't think it is warranted based on the scope of anticipated future changes; see my earlier post [1] for details. Nobody has seriously suggested that we would release this functionality and later eliminate the ability to override NumPy functions entirely in the future.
>
>
>
>
> Of course, requiring an onerous explicit opt-in would be fine while this feature is initially under development, and until we are sure that checks for overriding arbitrary NumPy functions are fast enough to be generally viable. In particular, we should verify that __array_function__ does not meaningfully impact performance for major downstream components of the SciPy stack. But I think running standard benchmark suites (e.g., with ASV) and user testing of release candidates would be enough.
>
> If you have still have major objections to this version of proposal, please raise them unambiguously -- preferably with an formal veto [2].
>
> Best,
> Stephan
>
>
>
>
> [1] https://mail.python.org/pipermail/numpy-discussion/2018-August/078669.html
> [2] https://docs.scipy.org/doc/numpy/dev/governance/governance.html
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion

+1 from me. The edits are readable and clean, and a good compromise.

Best Regards,
Hameer Abbasi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180913/b16900e6/attachment-0001.html>

From chunwei.yuan at gmail.com  Thu Sep 13 16:47:00 2018
From: chunwei.yuan at gmail.com (Chun-Wei Yuan)
Date: Thu, 13 Sep 2018 13:47:00 -0700
Subject: [Numpy-discussion] PR to add "weights" option to np.quantile
Message-ID: <CADNTXLJARg3J8GvOLpdb8Sd7xmBtxdLyRh=njVcU0rhyzf+vcQ@mail.gmail.com>

Hi all,

I have a long-standing PR to add a "weights" option to
np.quantile/percentile:

https://github.com/numpy/numpy/pull/9211

For a little background, there are quite a few ways to define "quantile" to
begin with.  Numpy defines it the same way as R's default (Type 7):

https://www.rdocumentation.org/packages/stats/versions/3.5.0/topics/quantile

What PR 9211 does is introducing a "weights" option while staying
consistent with the Type 7 definition of quantile.

There is certainly support on adding this feature, but as also can be
perused from the thread, there are doubts on

1.) what is the right way to define "weighted" quantile?
2.) whether Numpy should support other types of quantiles in the first
place, etc.

I've stated my answers to those questions in the thread.  This PR has
fallen off the radar and needs a little popular jolt to get some movement.
Please chime in to keep it alive.

Best,

Chun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180913/7b32e3c0/attachment.html>

From sseibert at anaconda.com  Fri Sep 14 15:24:58 2018
From: sseibert at anaconda.com (Stanley Seibert)
Date: Fri, 14 Sep 2018 14:24:58 -0500
Subject: [Numpy-discussion] CI Testing
In-Reply-To: <CAB6mnx+9C58PvZgciFk4mf=2dLnwZTyKLvYFEwXbrnBKqyRNeg@mail.gmail.com>
References: <CAB6mnxLx6DoC=Rw42BoBDvZjkFH64Q+_mPbA0U94Qny0mgfWTw@mail.gmail.com>
 <CADv3RKRKr7h9JbeYUoPq1z22CbH_0sfUuBzuqLg6tsipUfFttA@mail.gmail.com>
 <CAB6mnxL3jHwqgvE8nw2-iktbUHUjqL9DSe-Q+Jku03udwaV3Rg@mail.gmail.com>
 <CADv3RKSZ1ipW4-D_iVPna6G=5GkPx7R0C95NET4ag883maCsYQ@mail.gmail.com>
 <CAB6mnx+5SC30+kZP7P8PxseerbrAX=8xFROOZsZoALOGvVWVmA@mail.gmail.com>
 <CADv3RKSJxuiEYwdER642rB_xJw4Ohb73Zz--1JL_F=241arjUA@mail.gmail.com>
 <CADv3RKRfKArPQDHM0sSY9W8+LECp5SHGfav1dTmx_fXX1Ts_4A@mail.gmail.com>
 <CAB6mnx+9C58PvZgciFk4mf=2dLnwZTyKLvYFEwXbrnBKqyRNeg@mail.gmail.com>
Message-ID: <CADv3RKRpYMtzJ7ZGhK6CRcqNqd3kAL8r2BCj+L1cz-Q45Wku6g@mail.gmail.com>

On Thu, Sep 13, 2018 at 9:48 AM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
> On Thu, Sep 13, 2018 at 8:30 AM Stanley Seibert <sseibert at anaconda.com>
> wrote:
>
>> Another minor annoyance is that the link on the Github "Checks" page that
>> says "View More Details on Azure Pipelines" takes you to a login page,
>> which then forwards you to the public (no login required) pipeline build
>> results page.  As a result, people might not realize you can view the build
>> results for public projects without a Microsoft account, so you'll probably
>> want to put a build status badge with a direct link somewhere prominent in
>> the README.
>>
>> On Thu, Sep 13, 2018 at 9:25 AM, Stanley Seibert <sseibert at anaconda.com>
>> wrote:
>>
>>> I'm still trying to wrap my head around the security model here.  The
>>> onboarding wizard makes it pretty easy to get started, but the UI
>>> afterwards has a lot of complexity for managing fine grained permissions.
>>> As I understand it, I made a "numba" project with my Microsoft account, but
>>> I can add other Microsoft accounts to the project and give them varying
>>> access to administer the project.  None of these user accounts or
>>> permissions connect directly to Github accounts, so that is annoying if you
>>> have a large core dev team you want to give permission to manage builds.
>>> They will all need Microsoft accounts, and you will have to grant them
>>> admin access to the project.  (Still trying to figure out how to do that
>>> for Numba...)
>>>
>>> Azure Pipeline's connection to Github itself (to post CI status under
>>> PRs, etc) can be done either by granting permission via a Github user's
>>> account, or by installing it as an "app" in the Github organization, which
>>> is the route I opted for.
>>>
>>
> Does Azure Pipeline respond to the Github hooks? We have hooks for all the
> other testing sites.
>

I added Azure Pipelines as a "Github App" (or rather their setup wizard
did), which does similar things to web hooks, but for the entire Github
organization.  I think if had used their other setup method, it would have
installed as a Github webhook.  Either way, the behavior is the same,
though.  The Azure Pipeline builder automatically responds to Github events
like commits to master and new/updated PRs by running the pipeline, and
then updating the PR "checks" accordingly with the results.

I should also note that if someone adds Azure Pipeline support to NumPy's
repo and has a question, tag the product manager for Azure Pipelines
(github ID: @chrisrpatterson) in your PR.  He found the Numba PR where we
added Azure support, and was able to escalate one bug we had with the
Ubuntu workers very quickly.  They seem to be very eager to help adoption
by the open source community.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180914/123a1a56/attachment.html>

From matti.picus at gmail.com  Sun Sep 16 17:01:49 2018
From: matti.picus at gmail.com (Matti Picus)
Date: Mon, 17 Sep 2018 00:01:49 +0300
Subject: [Numpy-discussion] Adding `max_rows` to `loadtxt'
Message-ID: <3ea8e7da-2735-1c25-bafd-6eb14febb314@gmail.com>

A new contributor submitted a PR[0] to add `max_rows`[1] to `loadtxt`, 
like is done in 'genfromtxt', (which is used under the hood for 
'ndfromtxt', 'mafromtxt', and
'recfromtxt`).? Any thoughts?

[0] https://github.com/numpy/numpy/pull/11962
[1] Well, actually `maxlines`, but I asked to change it to `max_rows` to 
be consistent with `genfromtxt`.

Matti

From shoyer at gmail.com  Mon Sep 17 00:22:45 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Sun, 16 Sep 2018 21:22:45 -0700
Subject: [Numpy-discussion] Adding `max_rows` to `loadtxt'
In-Reply-To: <3ea8e7da-2735-1c25-bafd-6eb14febb314@gmail.com>
References: <3ea8e7da-2735-1c25-bafd-6eb14febb314@gmail.com>
Message-ID: <CAEQ_Tvfe8-3cJ0WHkCYm-ELBuYK=nNdRcUm7GwT-1cRGbJrj6g@mail.gmail.com>

This seems like a minor and uncontroversial improvement. No objections from
me!

On Sun, Sep 16, 2018 at 2:01 PM Matti Picus <matti.picus at gmail.com> wrote:

> A new contributor submitted a PR[0] to add `max_rows`[1] to `loadtxt`,
> like is done in 'genfromtxt', (which is used under the hood for
> 'ndfromtxt', 'mafromtxt', and
> 'recfromtxt`).  Any thoughts?
>
> [0] https://github.com/numpy/numpy/pull/11962
> [1] Well, actually `maxlines`, but I asked to change it to `max_rows` to
> be consistent with `genfromtxt`.
>
> Matti
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180916/a7c1d025/attachment.html>

From cimrman3 at ntc.zcu.cz  Mon Sep 17 05:45:11 2018
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Mon, 17 Sep 2018 11:45:11 +0200
Subject: [Numpy-discussion] ANN: SfePy 2018.3
Message-ID: <8de51b72-39b8-d407-471a-d8a7b5b2703e@ntc.zcu.cz>

I am pleased to announce release 2018.3 of SfePy.

Description
-----------

SfePy (simple finite elements in Python) is a software for solving systems of
coupled partial differential equations by the finite element method or by the
isogeometric analysis (limited support). It is distributed under the new BSD
license.

Home page: http://sfepy.org
Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/
Git (source) repository, issue tracker: https://github.com/sfepy/sfepy

Highlights of this release
--------------------------

- easier setting of values of variables
- new script for outline edge extraction
- new example: homogenization of a piezoelectric heterogeneous structure

For full release notes see http://docs.sfepy.org/doc/release_notes.html#id1
(rather long and technical).

Cheers,
Robert Cimrman

---

Contributors to this release in alphabetical order:

Robert Cimrman
Vladimir Lukes


From matthew.brett at gmail.com  Mon Sep 17 07:37:09 2018
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 17 Sep 2018 12:37:09 +0100
Subject: [Numpy-discussion] count_nonzero axis argument?
Message-ID: <CAH6Pt5rCTAyMOakZP52H=7xumb6-oTOuj6BwWziSDCnrFnTW7Q@mail.gmail.com>

Hi,

Is there any reason that np.count_nonzero should not take an axis
argument?  As in:

>>> np.better_count_nonzero([[10, 11], [0, 3]], axis=1)
array([2, 1])

It would be much more useful if it did...

Cheers,

Matthew

From jni.soma at gmail.com  Mon Sep 17 08:19:15 2018
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Mon, 17 Sep 2018 22:19:15 +1000
Subject: [Numpy-discussion] count_nonzero axis argument?
In-Reply-To: <CAH6Pt5rCTAyMOakZP52H=7xumb6-oTOuj6BwWziSDCnrFnTW7Q@mail.gmail.com>
References: <CAH6Pt5rCTAyMOakZP52H=7xumb6-oTOuj6BwWziSDCnrFnTW7Q@mail.gmail.com>
Message-ID: <1537186755.563956.1510675592.375411E2@webmail.messagingengine.com>

On Mon, Sep 17, 2018, at 9:37 PM, Matthew Brett wrote:
> >>> np.better_count_nonzero([[10, 11], [0, 3]], axis=1)
> array([2, 1])
> 
> It would be much more useful if it did...

You might know about this already, but I not too long ago discovered np.apply_along_axis [1], which is a magical function that makes all functions axis aware. Obviously I would support adding an axis keyword to count_nonzero, but in the meantime this function gets you there quickly!

Juan.

.. [1] https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.apply_along_axis.html

From sebastian at sipsolutions.net  Mon Sep 17 07:46:29 2018
From: sebastian at sipsolutions.net (Sebastian Berg)
Date: Mon, 17 Sep 2018 13:46:29 +0200
Subject: [Numpy-discussion] count_nonzero axis argument?
In-Reply-To: <CAH6Pt5rCTAyMOakZP52H=7xumb6-oTOuj6BwWziSDCnrFnTW7Q@mail.gmail.com>
References: <CAH6Pt5rCTAyMOakZP52H=7xumb6-oTOuj6BwWziSDCnrFnTW7Q@mail.gmail.com>
Message-ID: <b7be0c11e4948df1f1bbafe264ef0d38438b9772.camel@sipsolutions.net>

On Mon, 2018-09-17 at 12:37 +0100, Matthew Brett wrote:
> Hi,
> 
> Is there any reason that np.count_nonzero should not take an axis
> argument?  As in:
> 

No, sounds like an obvious improvement, but as also with those, someone
has to volunteer to do it...
Coding it will probably mean adding the NpyIter and possibly fast paths
(not sure about the state of count nonzero), but should not be very
difficult.

- Sebastian



> > > > np.better_count_nonzero([[10, 11], [0, 3]], axis=1)
> 
> array([2, 1])
> 
> It would be much more useful if it did...
> 
> Cheers,
> 
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180917/dd8fc5d3/attachment-0001.sig>

From warren.weckesser at gmail.com  Mon Sep 17 09:24:22 2018
From: warren.weckesser at gmail.com (Warren Weckesser)
Date: Mon, 17 Sep 2018 09:24:22 -0400
Subject: [Numpy-discussion] count_nonzero axis argument?
In-Reply-To: <CAH6Pt5rCTAyMOakZP52H=7xumb6-oTOuj6BwWziSDCnrFnTW7Q@mail.gmail.com>
References: <CAH6Pt5rCTAyMOakZP52H=7xumb6-oTOuj6BwWziSDCnrFnTW7Q@mail.gmail.com>
Message-ID: <CAGzF1uepx7AZ46DzYwhthLe_Te7aye5YOYeOxMBe6Gs5DHH1DA@mail.gmail.com>

On Mon, Sep 17, 2018 at 7:38 AM Matthew Brett <matthew.brett at gmail.com>
wrote:

> Hi,
>
> Is there any reason that np.count_nonzero should not take an axis
> argument?  As in:
>
> >>> np.better_count_nonzero([[10, 11], [0, 3]], axis=1)
> array([2, 1])
>
>

It already does (since version 1.12.0):
https://docs.scipy.org/doc/numpy/reference/generated/numpy.count_nonzero.html

Warren


It would be much more useful if it did...
>
> Cheers,
>
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180917/694b367c/attachment.html>

From matti.picus at gmail.com  Mon Sep 17 10:46:37 2018
From: matti.picus at gmail.com (Matti Picus)
Date: Mon, 17 Sep 2018 17:46:37 +0300
Subject: [Numpy-discussion] Search not working on
 www.numpy.org/devdocs/search.html
Message-ID: <d8493a71-106f-8995-7d59-c3e965d9a2b4@gmail.com>

I can enter a search term (say `ndarray`) in 
www.numpy.org/devdocs/search.html, but the result is empty. It worked 
yesterday. My firefox javascript debug console for the remote search says:

jQuery.Deferred exception: Search is not defined 
@http://www.numpy.org/devdocs/search.html?q=ndarray:34:25 
j at http://www.numpy.org/devdocs/_static/jquery.js:2:29997 
g/</k<@http://www.numpy.org/devdocs/_static/jquery.js:2:30313 undefined

If I build the documentation locally, search emits a different error but 
still works:

XML Parsing Error: not well-formed Location: 
file:///.../doc/build/html/searchindex.js Line Number 1, Column 16:

Searching on scipy.org, for instance 
https://docs.scipy.org/doc/numpy/search.html?q=ndarray&check_keywords=yes&area=default 
works with no errors on the console

Any hints?
Matti

From stefanv at berkeley.edu  Mon Sep 17 12:12:15 2018
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Mon, 17 Sep 2018 09:12:15 -0700
Subject: [Numpy-discussion] Adding `max_rows` to `loadtxt'
In-Reply-To: <CAEQ_Tvfe8-3cJ0WHkCYm-ELBuYK=nNdRcUm7GwT-1cRGbJrj6g@mail.gmail.com>
References: <3ea8e7da-2735-1c25-bafd-6eb14febb314@gmail.com>
 <CAEQ_Tvfe8-3cJ0WHkCYm-ELBuYK=nNdRcUm7GwT-1cRGbJrj6g@mail.gmail.com>
Message-ID: <165e84dc318.27ae.acf34a9c767d7bb498a799333be0433e@fastmail.com>

It looks good to me too, to especially with Eric's refinements.

Best regards,
St?fan

On September 16, 2018 21:23:44 Stephan Hoyer <shoyer at gmail.com> wrote:
> This seems like a minor and uncontroversial improvement. No objections from me!
>
> On Sun, Sep 16, 2018 at 2:01 PM Matti Picus <matti.picus at gmail.com> wrote:
> A new contributor submitted a PR[0] to add `max_rows`[1] to `loadtxt`,
> like is done in 'genfromtxt', (which is used under the hood for
> 'ndfromtxt', 'mafromtxt', and
> 'recfromtxt`).  Any thoughts?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180917/a5743c70/attachment.html>

From rainwoodman at gmail.com  Mon Sep 17 18:14:00 2018
From: rainwoodman at gmail.com (Feng Yu)
Date: Mon, 17 Sep 2018 15:14:00 -0700
Subject: [Numpy-discussion] Helper function for assignment from other
 structured arrays
Message-ID: <CANGhFjbnaCeZM4xSwUmDsoJNtgtKUKHc3Z_6rs0Jw9GrAC0uYQ@mail.gmail.com>

Hi,

Assignment between structured arrays are matching by the order of fields,
not by names of fields.

Is there a recommended way of assignment by matching field names? I can see
one way is to explicitly looping over the names; another possibility is to
use the field names of the target array to index the source array.

It would be nice if a recommended practice is provided as example near the
documentation on the topic:
https://docs.scipy.org/doc/numpy/user/basics.rec.html#assignment-from-other-structured-arrays

Thanks,

Yu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180917/ee0ac1e9/attachment.html>

From matthew.brett at gmail.com  Mon Sep 17 22:24:51 2018
From: matthew.brett at gmail.com (Matthew Brett)
Date: Tue, 18 Sep 2018 03:24:51 +0100
Subject: [Numpy-discussion] count_nonzero axis argument?
In-Reply-To: <CAGzF1uepx7AZ46DzYwhthLe_Te7aye5YOYeOxMBe6Gs5DHH1DA@mail.gmail.com>
References: <CAH6Pt5rCTAyMOakZP52H=7xumb6-oTOuj6BwWziSDCnrFnTW7Q@mail.gmail.com>
 <CAGzF1uepx7AZ46DzYwhthLe_Te7aye5YOYeOxMBe6Gs5DHH1DA@mail.gmail.com>
Message-ID: <CAH6Pt5oQ__xmGZ1LtM8nu77EWtD4q5pO_mefyWWMhsFUSgTc2A@mail.gmail.com>

On Mon, Sep 17, 2018 at 2:24 PM, Warren Weckesser
<warren.weckesser at gmail.com> wrote:
>
>
> On Mon, Sep 17, 2018 at 7:38 AM Matthew Brett <matthew.brett at gmail.com>
> wrote:
>>
>> Hi,
>>
>> Is there any reason that np.count_nonzero should not take an axis
>> argument?  As in:
>>
>> >>> np.better_count_nonzero([[10, 11], [0, 3]], axis=1)
>> array([2, 1])
>>
>
>
> It already does (since version 1.12.0):
> https://docs.scipy.org/doc/numpy/reference/generated/numpy.count_nonzero.html

Oops - sorry - I am so used to upgrading all the time, it didn't occur
to me I had an old version in my standard setup.  Thanks, and sorry
for the distraction.

Cheers,

Matthew

From shoyer at gmail.com  Tue Sep 18 15:26:38 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Tue, 18 Sep 2018 12:26:38 -0700
Subject: [Numpy-discussion] Tidelift
Message-ID: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>

Tidelift is a startup trying to make open source software more sustainable
by selling an open source subscription that pays maintainers.

NumPy is eligible for a guaranteed $10,000 over 24 months -- are we
interesting in signing up?
https://blog.tidelift.com/1m-to-pay-open-source-maintainers-on-tidelift
https://tidelift.com/lifter/search/pypi/numpy

It looks like they've started out focused on web development. NumPy is the
only project I see listed in the scientific computing space.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180918/1ea0997e/attachment.html>

From shoyer at gmail.com  Tue Sep 18 17:54:33 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Tue, 18 Sep 2018 14:54:33 -0700
Subject: [Numpy-discussion] Tidelift
In-Reply-To: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
References: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
Message-ID: <CAEQ_TvdvkEkVrLuo=qOc-d9PfUVVps2wvZ0PosH7EVAx9LfdrA@mail.gmail.com>

On Tue, Sep 18, 2018 at 12:26 PM Stephan Hoyer <shoyer at gmail.com> wrote:

> Tidelift is a startup trying to make open source software more sustainable
> by selling an open source subscription that pays maintainers.
>
> NumPy is eligible for a guaranteed $10,000 over 24 months -- are we
> interesting in signing up?
> https://blog.tidelift.com/1m-to-pay-open-source-maintainers-on-tidelift
> https://tidelift.com/lifter/search/pypi/numpy
>
> It looks like they've started out focused on web development. NumPy is the
> only project I see listed in the scientific computing space.
>

It occurs to me that NumFOCUS is probably worth looping into any such
discussion, given the strong overlap between Tidelift and NumFOCUS's goals
and the nature of our NumFOCUS affiliation.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180918/6dec6e86/attachment.html>

From andy.terrel at gmail.com  Tue Sep 18 17:54:16 2018
From: andy.terrel at gmail.com (Andy Ray Terrel)
Date: Tue, 18 Sep 2018 16:54:16 -0500
Subject: [Numpy-discussion] Tidelift
In-Reply-To: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
References: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
Message-ID: <CA+WonSQZC+J-ifj2=nfF4MCoEyVZ8eACYM2KHcVENi8BEi2Ecw@mail.gmail.com>

FYI, Donald Fischer will be at the NumFOCUS forum next week if folks want
to talk to him about it. It looks like individuals sign up with Tidelift
and perform services to be paid this money. Looking at the contract it
doesn't seem like something that works with anything but individuals or for
profit companies. Thus I don't know that "Numpy is eligible" more that
"Numpy developers are eligible".

On Tue, Sep 18, 2018 at 2:27 PM Stephan Hoyer <shoyer at gmail.com> wrote:

> Tidelift is a startup trying to make open source software more sustainable
> by selling an open source subscription that pays maintainers.
>
> NumPy is eligible for a guaranteed $10,000 over 24 months -- are we
> interesting in signing up?
> https://blog.tidelift.com/1m-to-pay-open-source-maintainers-on-tidelift
> https://tidelift.com/lifter/search/pypi/numpy
>
> It looks like they've started out focused on web development. NumPy is the
> only project I see listed in the scientific computing space.
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180918/d89f458b/attachment.html>

From andy.terrel at gmail.com  Tue Sep 18 17:58:31 2018
From: andy.terrel at gmail.com (Andy Ray Terrel)
Date: Tue, 18 Sep 2018 16:58:31 -0500
Subject: [Numpy-discussion] Tidelift
In-Reply-To: <CAEQ_TvdvkEkVrLuo=qOc-d9PfUVVps2wvZ0PosH7EVAx9LfdrA@mail.gmail.com>
References: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
 <CAEQ_TvdvkEkVrLuo=qOc-d9PfUVVps2wvZ0PosH7EVAx9LfdrA@mail.gmail.com>
Message-ID: <CA+WonSQpF8qDgvLMG6Nps0vPvtc0CFT0tbwk3iEcDHT1KcjazQ@mail.gmail.com>

On Tue, Sep 18, 2018 at 4:55 PM Stephan Hoyer <shoyer at gmail.com> wrote:

> On Tue, Sep 18, 2018 at 12:26 PM Stephan Hoyer <shoyer at gmail.com> wrote:
>
>> Tidelift is a startup trying to make open source software more
>> sustainable by selling an open source subscription that pays maintainers.
>>
>> NumPy is eligible for a guaranteed $10,000 over 24 months -- are we
>> interesting in signing up?
>> https://blog.tidelift.com/1m-to-pay-open-source-maintainers-on-tidelift
>> https://tidelift.com/lifter/search/pypi/numpy
>>
>> It looks like they've started out focused on web development. NumPy is
>> the only project I see listed in the scientific computing space.
>>
>
> It occurs to me that NumFOCUS is probably worth looping into any such
> discussion, given the strong overlap between Tidelift and NumFOCUS's goals
> and the nature of our NumFOCUS affiliation.
>

Yeah I'm reaching out to Don as we speak. I've known him for a number of
years and chatted about NumFOCUS working with Tidelift last year but this
program didn't exist.  I think the real game changer is having an automated
way to scan a clients code base and spit out the dependencies. I would love
to have that to take to every institute we work with. "Here NASA if you
don't support these codes the next rover could die" =D


> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180918/a9b37c28/attachment.html>

From m.h.vankerkwijk at gmail.com  Tue Sep 18 20:05:53 2018
From: m.h.vankerkwijk at gmail.com (Marten van Kerkwijk)
Date: Tue, 18 Sep 2018 20:05:53 -0400
Subject: [Numpy-discussion] Tidelift
In-Reply-To: <CA+WonSQpF8qDgvLMG6Nps0vPvtc0CFT0tbwk3iEcDHT1KcjazQ@mail.gmail.com>
References: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
 <CAEQ_TvdvkEkVrLuo=qOc-d9PfUVVps2wvZ0PosH7EVAx9LfdrA@mail.gmail.com>
 <CA+WonSQpF8qDgvLMG6Nps0vPvtc0CFT0tbwk3iEcDHT1KcjazQ@mail.gmail.com>
Message-ID: <CAJNV+9vdZdiKbLy7fvq0XV9EpQCTGP+u746A_+8HTrRNaiR_7Q@mail.gmail.com>

> Yeah I'm reaching out to Don as we speak. I've known him for a number of
> years and chatted about NumFOCUS working with Tidelift last year but this
> program didn't exist.  I think the real game changer is having an automated
> way to scan a clients code base and spit out the dependencies. I would love
> to have that to take to every institute we work with. "Here NASA if you
> don't support these codes the next rover could die" =D
>

I agree with the sentiment but you may need a better example...  At least,
numarray (which, with numeric, became numpy) was developed at NASA's Space
Telescope Science Institute; and the same institute has been paying several
developers of astropy (partially as they see it as the best way to get good
data analysis pipelines for the upcoming James Webb Space Telescope), one
of which was Michael Droetboom (who you may know from matplotlib). Overall,
in astronomy at least, NASA has been a wonderful force for open data and
software.

-- Marten.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180918/cfcc6ed5/attachment-0001.html>

From tcaswell at gmail.com  Tue Sep 18 20:43:56 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Tue, 18 Sep 2018 20:43:56 -0400
Subject: [Numpy-discussion] [REL] Matplotlib 3.0.0
Message-ID: <CAA48SF98XHAnBs56MhwgSjkcqkWznPppquZRCoC5Pwnz9wOXfw@mail.gmail.com>

Folks,

Happy to announce Matplotlib 3.0.0!

This is the first version of Matplotlib to only support Python 3.

If you need Python 2.7 support the 2.2.x LTS series will continue to
receive critical bug-fixes until 2020.

Highlights of this release include:

 - GUI backend is selected at run-time based on what toolkits are
   installed.  A GUI toolkit will not be selected on a headless
   server.
 - New cyclic color map *twilight*
 - Improvements to automatic layout of titles, ticks, and GridSpec
 - Many bug fixes!

For the full details see  https://matplotlib.org/users/whats_new.html and
https://matplotlib.org/api/api_changes.html for whats new and API changes
respectively.

For packagers: Matplotlib no longer depends on six or pytz.

A big thank you to everyone who worked on this release in terms of commits
(~130 people have commits), reporting issues, and review.

I expect there to be a v3.0.1 release in the next month or so.

Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180918/de4214bb/attachment.html>

From stefanv at berkeley.edu  Tue Sep 18 21:04:56 2018
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Tue, 18 Sep 2018 18:04:56 -0700
Subject: [Numpy-discussion] Tidelift
In-Reply-To: <CA+WonSQZC+J-ifj2=nfF4MCoEyVZ8eACYM2KHcVENi8BEi2Ecw@mail.gmail.com>
References: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
 <CA+WonSQZC+J-ifj2=nfF4MCoEyVZ8eACYM2KHcVENi8BEi2Ecw@mail.gmail.com>
Message-ID: <20180919010456.hi46n3siifw6r25w@carbo>

On Tue, 18 Sep 2018 16:54:16 -0500, Andy Ray Terrel wrote:
> FYI, Donald Fischer will be at the NumFOCUS forum next week if folks want
> to talk to him about it. It looks like individuals sign up with Tidelift
> and perform services to be paid this money. Looking at the contract it
> doesn't seem like something that works with anything but individuals or for
> profit companies. Thus I don't know that "Numpy is eligible" more that
> "Numpy developers are eligible".

On the website, they ask that all the maintainers discuss together how
the funds will be applied (the total given is for the project as a
whole).

This seems tricky: all the maintainers are spending their time on the
project.  Which ones will get paid?  Will the ones getting paid be
expected to put in extra hours on top of what they are already doing, or
will they carry a more "formal" responsibility?  Perhaps it makes sense
to fund specific activities, such as being release manager, that
increase the amount of time donated to the project?

There are other subtleties: some developers work for companies that do
not allow them to get paid for external consulting, others have visa
issues that prevent them from working for compensation.

One useful gain could be to incentivize those who would otherwise not be
able to contribute.  Parents taking care of children, those who take
second jobs to survive, students, etc. [0]

Best regards,
St?fan


[0] Quoting Fernando P?rez: "When people are expected to work on open
    source software for free, only the people who can afford to work for
    free can participate".

From andy.terrel at gmail.com  Tue Sep 18 21:47:28 2018
From: andy.terrel at gmail.com (Andy Ray Terrel)
Date: Tue, 18 Sep 2018 20:47:28 -0500
Subject: [Numpy-discussion] Tidelift
In-Reply-To: <20180919010456.hi46n3siifw6r25w@carbo>
References: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
 <CA+WonSQZC+J-ifj2=nfF4MCoEyVZ8eACYM2KHcVENi8BEi2Ecw@mail.gmail.com>
 <20180919010456.hi46n3siifw6r25w@carbo>
Message-ID: <CA+WonSQ_JmO6sgfYeBy-HQ-tPyp1waLGY=aiFVvjg2eHKdcbZw@mail.gmail.com>

I've forwarded Donald this conversation. He said he is working on some of
the finer details. He's up for chatting more in NYC next week so if we want
to collect a set of questions it might be easy to get them all figured out
there.

On Tue, Sep 18, 2018 at 8:06 PM Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> On Tue, 18 Sep 2018 16:54:16 -0500, Andy Ray Terrel wrote:
> > FYI, Donald Fischer will be at the NumFOCUS forum next week if folks want
> > to talk to him about it. It looks like individuals sign up with Tidelift
> > and perform services to be paid this money. Looking at the contract it
> > doesn't seem like something that works with anything but individuals or
> for
> > profit companies. Thus I don't know that "Numpy is eligible" more that
> > "Numpy developers are eligible".
>
> On the website, they ask that all the maintainers discuss together how
> the funds will be applied (the total given is for the project as a
> whole).
>
> This seems tricky: all the maintainers are spending their time on the
> project.  Which ones will get paid?  Will the ones getting paid be
> expected to put in extra hours on top of what they are already doing, or
> will they carry a more "formal" responsibility?  Perhaps it makes sense
> to fund specific activities, such as being release manager, that
> increase the amount of time donated to the project?
>
> There are other subtleties: some developers work for companies that do
> not allow them to get paid for external consulting, others have visa
> issues that prevent them from working for compensation.
>
> One useful gain could be to incentivize those who would otherwise not be
> able to contribute.  Parents taking care of children, those who take
> second jobs to survive, students, etc. [0]
>
> Best regards,
> St?fan
>
>
> [0] Quoting Fernando P?rez: "When people are expected to work on open
>     source software for free, only the people who can afford to work for
>     free can participate".
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180918/166885aa/attachment.html>

From njs at pobox.com  Tue Sep 18 23:00:56 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Tue, 18 Sep 2018 20:00:56 -0700
Subject: [Numpy-discussion] Tidelift
In-Reply-To: <20180919010456.hi46n3siifw6r25w@carbo>
References: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
 <CA+WonSQZC+J-ifj2=nfF4MCoEyVZ8eACYM2KHcVENi8BEi2Ecw@mail.gmail.com>
 <20180919010456.hi46n3siifw6r25w@carbo>
Message-ID: <CAPJVwBmVrF2MK=itczsd4_2B5hd8PF1WR7MTKgX+OAQ3aQQBQg@mail.gmail.com>

On Tue, Sep 18, 2018 at 6:04 PM, Stefan van der Walt
<stefanv at berkeley.edu> wrote:
> On Tue, 18 Sep 2018 16:54:16 -0500, Andy Ray Terrel wrote:
>> FYI, Donald Fischer will be at the NumFOCUS forum next week if folks want
>> to talk to him about it. It looks like individuals sign up with Tidelift
>> and perform services to be paid this money. Looking at the contract it
>> doesn't seem like something that works with anything but individuals or for
>> profit companies. Thus I don't know that "Numpy is eligible" more that
>> "Numpy developers are eligible".
>
> On the website, they ask that all the maintainers discuss together how
> the funds will be applied (the total given is for the project as a
> whole).
>
> This seems tricky: all the maintainers are spending their time on the
> project.  Which ones will get paid?  Will the ones getting paid be
> expected to put in extra hours on top of what they are already doing, or
> will they carry a more "formal" responsibility?  Perhaps it makes sense
> to fund specific activities, such as being release manager, that
> increase the amount of time donated to the project?
>
> There are other subtleties: some developers work for companies that do
> not allow them to get paid for external consulting, others have visa
> issues that prevent them from working for compensation.
>
> One useful gain could be to incentivize those who would otherwise not be
> able to contribute.  Parents taking care of children, those who take
> second jobs to survive, students, etc. [0]

Assuming the details work out, and that it really is "free money" for
doing the things we're already doing, then I guess the obvious
approach would be to accept, put the money into the NumFOCUS project
account (alongside the money we get from donations etc.), and then
distribute it using the existing mechanisms for managing that money.
If it's really only $5k/year, then that's comparable to what we
currently get and we can use it to fund meetings or whatever; if it's
more, then we can consider using some to contract with individuals to
work on numpy, or whatever makes sense.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From andy.terrel at gmail.com  Tue Sep 18 23:29:47 2018
From: andy.terrel at gmail.com (Andy Ray Terrel)
Date: Tue, 18 Sep 2018 22:29:47 -0500
Subject: [Numpy-discussion] Tidelift
In-Reply-To: <CAPJVwBmVrF2MK=itczsd4_2B5hd8PF1WR7MTKgX+OAQ3aQQBQg@mail.gmail.com>
References: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
 <CA+WonSQZC+J-ifj2=nfF4MCoEyVZ8eACYM2KHcVENi8BEi2Ecw@mail.gmail.com>
 <20180919010456.hi46n3siifw6r25w@carbo>
 <CAPJVwBmVrF2MK=itczsd4_2B5hd8PF1WR7MTKgX+OAQ3aQQBQg@mail.gmail.com>
Message-ID: <CA+WonSTUdMS=sAmLk38RbiKZ8Fmp=u+V0-Zk4EYx1uBoVEQ_Hw@mail.gmail.com>

On Tue, Sep 18, 2018 at 10:01 PM Nathaniel Smith <njs at pobox.com> wrote:

> On Tue, Sep 18, 2018 at 6:04 PM, Stefan van der Walt
> <stefanv at berkeley.edu> wrote:
> > On Tue, 18 Sep 2018 16:54:16 -0500, Andy Ray Terrel wrote:
> >> FYI, Donald Fischer will be at the NumFOCUS forum next week if folks
> want
> >> to talk to him about it. It looks like individuals sign up with Tidelift
> >> and perform services to be paid this money. Looking at the contract it
> >> doesn't seem like something that works with anything but individuals or
> for
> >> profit companies. Thus I don't know that "Numpy is eligible" more that
> >> "Numpy developers are eligible".
> >
> > On the website, they ask that all the maintainers discuss together how
> > the funds will be applied (the total given is for the project as a
> > whole).
> >
> > This seems tricky: all the maintainers are spending their time on the
> > project.  Which ones will get paid?  Will the ones getting paid be
> > expected to put in extra hours on top of what they are already doing, or
> > will they carry a more "formal" responsibility?  Perhaps it makes sense
> > to fund specific activities, such as being release manager, that
> > increase the amount of time donated to the project?
> >
> > There are other subtleties: some developers work for companies that do
> > not allow them to get paid for external consulting, others have visa
> > issues that prevent them from working for compensation.
> >
> > One useful gain could be to incentivize those who would otherwise not be
> > able to contribute.  Parents taking care of children, those who take
> > second jobs to survive, students, etc. [0]
>
> Assuming the details work out, and that it really is "free money" for
> doing the things we're already doing, then I guess the obvious
> approach would be to accept, put the money into the NumFOCUS project
> account (alongside the money we get from donations etc.), and then
> distribute it using the existing mechanisms for managing that money.
> If it's really only $5k/year, then that's comparable to what we
> currently get and we can use it to fund meetings or whatever; if it's
> more, then we can consider using some to contract with individuals to
> work on numpy, or whatever makes sense.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org




The contract [0] mentions:

 "Tidelift wants to pay you to provide certain software maintenance,
support, analysis, or other services to Tidelift and Tidelift?s Subscribers
(the ?Service,? as further defined below), and you want to provide such
services."

Depending on the context of these services, money to a 501c3 might not be
the best approach. There is some nuance to whether a company is paying for
a public good or a non-profit is providing a private service. At a minimum
if it is really "only doing the work maintainers do anyways" then we need
to write a better contract that says that. On the other hand if it is $5K
for a small set of independent consultants, it might be nice money for
folks but is a far cry from "paying the maintainers" model that they are
marketing, more like "paying consultants" which is a lucrative business for
many already. I would love to see it grow to paying a living wage to all
maintainers so I think it is in our interest to try and help Tidelift
overcome some of these challenges.

-- Andy

[0] https://tidelift.com/docs/lifting/agreement

On Tue, Sep 18, 2018 at 10:01 PM Nathaniel Smith <njs at pobox.com> wrote:

> On Tue, Sep 18, 2018 at 6:04 PM, Stefan van der Walt
> <stefanv at berkeley.edu> wrote:
> > On Tue, 18 Sep 2018 16:54:16 -0500, Andy Ray Terrel wrote:
> >> FYI, Donald Fischer will be at the NumFOCUS forum next week if folks
> want
> >> to talk to him about it. It looks like individuals sign up with Tidelift
> >> and perform services to be paid this money. Looking at the contract it
> >> doesn't seem like something that works with anything but individuals or
> for
> >> profit companies. Thus I don't know that "Numpy is eligible" more that
> >> "Numpy developers are eligible".
> >
> > On the website, they ask that all the maintainers discuss together how
> > the funds will be applied (the total given is for the project as a
> > whole).
> >
> > This seems tricky: all the maintainers are spending their time on the
> > project.  Which ones will get paid?  Will the ones getting paid be
> > expected to put in extra hours on top of what they are already doing, or
> > will they carry a more "formal" responsibility?  Perhaps it makes sense
> > to fund specific activities, such as being release manager, that
> > increase the amount of time donated to the project?
> >
> > There are other subtleties: some developers work for companies that do
> > not allow them to get paid for external consulting, others have visa
> > issues that prevent them from working for compensation.
> >
> > One useful gain could be to incentivize those who would otherwise not be
> > able to contribute.  Parents taking care of children, those who take
> > second jobs to survive, students, etc. [0]
>
> Assuming the details work out, and that it really is "free money" for
> doing the things we're already doing, then I guess the obvious
> approach would be to accept, put the money into the NumFOCUS project
> account (alongside the money we get from donations etc.), and then
> distribute it using the existing mechanisms for managing that money.
> If it's really only $5k/year, then that's comparable to what we
> currently get and we can use it to fund meetings or whatever; if it's
> more, then we can consider using some to contract with individuals to
> work on numpy, or whatever makes sense.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180918/2f249b3e/attachment.html>

From ralf.gommers at gmail.com  Tue Sep 18 23:34:53 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 18 Sep 2018 20:34:53 -0700
Subject: [Numpy-discussion] Tidelift
In-Reply-To: <CA+WonSTUdMS=sAmLk38RbiKZ8Fmp=u+V0-Zk4EYx1uBoVEQ_Hw@mail.gmail.com>
References: <CAEQ_TveRUNMBNy3BT+C6_aKsVr2oqmBD8df1tONhff=mC4Tr7Q@mail.gmail.com>
 <CA+WonSQZC+J-ifj2=nfF4MCoEyVZ8eACYM2KHcVENi8BEi2Ecw@mail.gmail.com>
 <20180919010456.hi46n3siifw6r25w@carbo>
 <CAPJVwBmVrF2MK=itczsd4_2B5hd8PF1WR7MTKgX+OAQ3aQQBQg@mail.gmail.com>
 <CA+WonSTUdMS=sAmLk38RbiKZ8Fmp=u+V0-Zk4EYx1uBoVEQ_Hw@mail.gmail.com>
Message-ID: <CABL7CQjnN=r-0weqJ0JXku8-POmLjfi6ED4RUn0UXcZCBEPJzg@mail.gmail.com>

On Tue, Sep 18, 2018 at 8:30 PM Andy Ray Terrel <andy.terrel at gmail.com>
wrote:

>
>
> On Tue, Sep 18, 2018 at 10:01 PM Nathaniel Smith <njs at pobox.com> wrote:
>
>> On Tue, Sep 18, 2018 at 6:04 PM, Stefan van der Walt
>> <stefanv at berkeley.edu> wrote:
>> > On Tue, 18 Sep 2018 16:54:16 -0500, Andy Ray Terrel wrote:
>> >> FYI, Donald Fischer will be at the NumFOCUS forum next week if folks
>> want
>> >> to talk to him about it. It looks like individuals sign up with
>> Tidelift
>> >> and perform services to be paid this money. Looking at the contract it
>> >> doesn't seem like something that works with anything but individuals
>> or for
>> >> profit companies. Thus I don't know that "Numpy is eligible" more that
>> >> "Numpy developers are eligible".
>> >
>> > On the website, they ask that all the maintainers discuss together how
>> > the funds will be applied (the total given is for the project as a
>> > whole).
>> >
>> > This seems tricky: all the maintainers are spending their time on the
>> > project.  Which ones will get paid?  Will the ones getting paid be
>> > expected to put in extra hours on top of what they are already doing, or
>> > will they carry a more "formal" responsibility?  Perhaps it makes sense
>> > to fund specific activities, such as being release manager, that
>> > increase the amount of time donated to the project?
>> >
>> > There are other subtleties: some developers work for companies that do
>> > not allow them to get paid for external consulting, others have visa
>> > issues that prevent them from working for compensation.
>>
>
I agree, most people with regular employment contracts  will either not be
able to do this, or spend significant effort (e.g. submitting and getting
their employer to sign a conflict of interest statement). See
https://tidelift.com/docs/lifting/agreement - that's a lot of legalese to
deal with. Also, you'll become responsible for taxes etc.



> >
>> > One useful gain could be to incentivize those who would otherwise not be
>> > able to contribute.  Parents taking care of children, those who take
>> > second jobs to survive, students, etc. [0]
>>
>> Assuming the details work out, and that it really is "free money" for
>> doing the things we're already doing,
>
>
it's not, there's definitely paperwork involved which is not free. plus
you're giving some kind of guarantee, so in case of license issues etc the
person(s) who sign up are committed to work on them - no hard timeline
given, but clearly an expectation.

then I guess the obvious
>> approach would be to accept, put the money into the NumFOCUS project
>> account (alongside the money we get from donations etc.), and then
>> distribute it using the existing mechanisms for managing that money.
>> If it's really only $5k/year, then that's comparable to what we
>> currently get and we can use it to fund meetings or whatever; if it's
>> more, then we can consider using some to contract with individuals to
>> work on numpy, or whatever makes sense.
>>
>> -n
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>
>
>
>
> The contract [0] mentions:
>
>  "Tidelift wants to pay you to provide certain software maintenance,
> support, analysis, or other services to Tidelift and Tidelift?s Subscribers
> (the ?Service,? as further defined below), and you want to provide such
> services."
>
> Depending on the context of these services, money to a 501c3 might not be
> the best approach. There is some nuance to whether a company is paying for
> a public good or a non-profit is providing a private service. At a minimum
> if it is really "only doing the work maintainers do anyways" then we need
> to write a better contract that says that. On the other hand if it is $5K
> for a small set of independent consultants, it might be nice money for
> folks but is a far cry from "paying the maintainers" model that they are
> marketing, more like "paying consultants" which is a lucrative business for
> many already. I would love to see it grow to paying a living wage to all
> maintainers so I think it is in our interest to try and help Tidelift
> overcome some of these challenges.
>

I agree.

Ralf


> -- Andy
>
> [0] https://tidelift.com/docs/lifting/agreement
>
> On Tue, Sep 18, 2018 at 10:01 PM Nathaniel Smith <njs at pobox.com> wrote:
>
>> On Tue, Sep 18, 2018 at 6:04 PM, Stefan van der Walt
>> <stefanv at berkeley.edu> wrote:
>> > On Tue, 18 Sep 2018 16:54:16 -0500, Andy Ray Terrel wrote:
>> >> FYI, Donald Fischer will be at the NumFOCUS forum next week if folks
>> want
>> >> to talk to him about it. It looks like individuals sign up with
>> Tidelift
>> >> and perform services to be paid this money. Looking at the contract it
>> >> doesn't seem like something that works with anything but individuals
>> or for
>> >> profit companies. Thus I don't know that "Numpy is eligible" more that
>> >> "Numpy developers are eligible".
>> >
>> > On the website, they ask that all the maintainers discuss together how
>> > the funds will be applied (the total given is for the project as a
>> > whole).
>> >
>> > This seems tricky: all the maintainers are spending their time on the
>> > project.  Which ones will get paid?  Will the ones getting paid be
>> > expected to put in extra hours on top of what they are already doing, or
>> > will they carry a more "formal" responsibility?  Perhaps it makes sense
>> > to fund specific activities, such as being release manager, that
>> > increase the amount of time donated to the project?
>> >
>> > There are other subtleties: some developers work for companies that do
>> > not allow them to get paid for external consulting, others have visa
>> > issues that prevent them from working for compensation.
>> >
>> > One useful gain could be to incentivize those who would otherwise not be
>> > able to contribute.  Parents taking care of children, those who take
>> > second jobs to survive, students, etc. [0]
>>
>> Assuming the details work out, and that it really is "free money" for
>> doing the things we're already doing, then I guess the obvious
>> approach would be to accept, put the money into the NumFOCUS project
>> account (alongside the money we get from donations etc.), and then
>> distribute it using the existing mechanisms for managing that money.
>> If it's really only $5k/year, then that's comparable to what we
>> currently get and we can use it to fund meetings or whatever; if it's
>> more, then we can consider using some to contract with individuals to
>> work on numpy, or whatever makes sense.
>>
>> -n
>>
>> --
>> Nathaniel J. Smith -- https://vorpus.org
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180918/47a919fe/attachment-0001.html>

From tcaswell at gmail.com  Wed Sep 19 10:03:12 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Wed, 19 Sep 2018 10:03:12 -0400
Subject: [Numpy-discussion] [REL] Matplotlib 3.0.0
In-Reply-To: <CAA48SF98XHAnBs56MhwgSjkcqkWznPppquZRCoC5Pwnz9wOXfw@mail.gmail.com>
References: <CAA48SF98XHAnBs56MhwgSjkcqkWznPppquZRCoC5Pwnz9wOXfw@mail.gmail.com>
Message-ID: <CAA48SF_D7YUYqb06om7rprOs0N9Hir-mAmfV5PNQarrbh9+REA@mail.gmail.com>

Folks,

A small update, when I uploaded the wheels yesterday I only uploaded about
half of them [1] and did not check my work carefully enough.  This has been
rectified, sorry to everyone who had installs fail his morning.

Tom

[1] I downoladed one of the wheels from http://wheels.scipy.org/ twice, the
browser helpfully added (1) to the name, when I when to upload everything
twine got half way through and failed out on that file.  I thought it had
done everything else, but it had actually only done everything up to that
file.

On Tue, Sep 18, 2018 at 8:43 PM Thomas Caswell <tcaswell at gmail.com> wrote:

> Folks,
>
> Happy to announce Matplotlib 3.0.0!
>
> This is the first version of Matplotlib to only support Python 3.
>
> If you need Python 2.7 support the 2.2.x LTS series will continue to
> receive critical bug-fixes until 2020.
>
> Highlights of this release include:
>
>  - GUI backend is selected at run-time based on what toolkits are
>    installed.  A GUI toolkit will not be selected on a headless
>    server.
>  - New cyclic color map *twilight*
>  - Improvements to automatic layout of titles, ticks, and GridSpec
>  - Many bug fixes!
>
> For the full details see  https://matplotlib.org/users/whats_new.html
> and  https://matplotlib.org/api/api_changes.html for whats new and API
> changes respectively.
>
> For packagers: Matplotlib no longer depends on six or pytz.
>
> A big thank you to everyone who worked on this release in terms of commits
> (~130 people have commits), reporting issues, and review.
>
> I expect there to be a v3.0.1 release in the next month or so.
>
> Tom
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180919/e1df0054/attachment.html>

From charlesr.harris at gmail.com  Wed Sep 19 11:30:55 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Wed, 19 Sep 2018 09:30:55 -0600
Subject: [Numpy-discussion] NumPy 1.15.2
Message-ID: <CAB6mnxKskk=uDGvKSDn9DSZ6gwtj4=4MfWPxsb8FqS8QKUiiag@mail.gmail.com>

Hi All,

I'm planning to make a NumPy 1.15.2 release this coming weekend in order to
deal with a couple of bugs. The fixes queued up for the release can be seen
here
<https://github.com/numpy/numpy/pulls?utf8=%E2%9C%93&q=milestone%3A%221.15.2+release%22+>.
If you think that there should be addition, please comment.

Cheers,

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180919/7f5f75a2/attachment.html>

From shoyer at gmail.com  Wed Sep 19 12:31:17 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Wed, 19 Sep 2018 09:31:17 -0700
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
 <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
Message-ID: <CAEQ_TvdCC70Wnukb73aYJM1dSf9Xf62f=bvaKaXFbBFkLNfBzw@mail.gmail.com>

On Thu, Sep 13, 2018 at 10:30 AM Stephan Hoyer <shoyer at gmail.com> wrote:

> On Sat, Sep 8, 2018 at 7:12 PM Charles R Harris <charlesr.harris at gmail.com>
> wrote:
>
>> On Wed, Aug 1, 2018 at 6:27 PM Stephan Hoyer <shoyer at gmail.com> wrote:
>>
>>> I propose to accept NEP-18, "A dispatch mechanism for NumPy?s high level
>>> array functions":
>>> http://www.numpy.org/neps/nep-0018-array-function-protocol.html
>>>
>>> Since the last round of discussion, we added a new section on "Callable
>>> objects generated at runtime" clarifying that to handle such objects is out
>>> of scope for the initial proposal in the NEP.
>>>
>>> If there are no substantive objections within 7 days from this email,
>>> then the NEP will be accepted; see NEP 0 for more details.
>>>
>>>
>> I've merged the PR. What next?
>>
>> Chuck
>>
>
> I rolled back Chuck's merge of the "Acceptance" PR for this NEP because
> (1) it was not clear that if had reached consensus and (2) I still wanted
> to make a few changes based on this discussion.
>
> I have now drafted these revisions to the NEP to clarify its stance around
> backwards compatibility, and the type of the "types" argument:
> https://github.com/numpy/numpy/pull/11943
>
> I have *not* included any form of the explicit "end-user opt-in" requested
> by Nathaniel. I don't think it is warranted based on the scope of
> anticipated future changes; see my earlier post [1] for details. Nobody has
> seriously suggested that we would release this functionality and later
> eliminate the ability to override NumPy functions entirely in the future.
>
> Of course, requiring an onerous explicit opt-in would be fine while this
> feature is initially under development, and until we are sure that checks
> for overriding arbitrary NumPy functions are fast enough to be generally
> viable. In particular, we should verify that __array_function__ does not
> meaningfully impact performance for major downstream components of the
> SciPy stack. But I think running standard benchmark suites (e.g., with ASV)
> and user testing of release candidates would be enough.
>
> If you have still have major objections to this version of proposal,
> please raise them unambiguously -- preferably with an formal veto [2].
>

Again, if anyone (yes, I'm looking at you, Nathaniel!) still has objections
please speak up soon.

If I don't hear anything, I'm going submit a PR to mark this proposal as
"Accepted" tomorrow (one week after these latest revisions).

As Chuck noted, "Tentatively accepted" or "Experimental" would probably be
a better status, but that currently isn't one of our options for NEPs. In
any case, I would love to move on from debate to implementation!

As a side note, I recently noticed a CuPy pull request (
https://github.com/cupy/cupy/pull/1650
<https://github.com/cupy/cupy/pull/1650/files>) to add __array_function__.
It's a testament to our proposed interface that the full PR is 9 lines of
code without tests.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180919/60ad0f4d/attachment.html>

From njs at pobox.com  Thu Sep 20 05:33:46 2018
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 20 Sep 2018 02:33:46 -0700
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
 <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
Message-ID: <CAPJVwB=0Th2q03WGJvidKVJwB6-S+Lt5GgZ+baFonY8y5ag1rQ@mail.gmail.com>

On Thu, Sep 13, 2018 at 10:30 AM, Stephan Hoyer <shoyer at gmail.com> wrote:
> I have now drafted these revisions to the NEP to clarify its stance around
> backwards compatibility, and the type of the "types" argument:
> https://github.com/numpy/numpy/pull/11943

Okay, so this is a pretty substantial change! Before, the NEP's stance
was "we might change anything, at any time, without any warning",
which of course makes it easier to accept the NEP (since we can always
back out), but was also so different from our normal rules that it
seemed important to make sure people weren't using it without
realizing. Now it actually makes a commitment: to not regress on what
functions can be overloaded (though the details might change), and
commits to an abbreviated-but-nonzero deprecation process when we
change things. I get the impression that this is closer to what the
authors were intending in the first place, so that's good! I would
probably have kept the noisy warning and zero commitments for one
release anyway, because IMO it's not a big deal and it rarely hurts to
hedge bets and gather data. But on reflection, I think I am OK with
this level of commitment if that's what y'all want to go for. (After
all, it's not really any stronger than NEP 22's high-level plan.) So,
+0.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From shoyer at gmail.com  Thu Sep 20 17:05:00 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Thu, 20 Sep 2018 14:05:00 -0700
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAPJVwB=0Th2q03WGJvidKVJwB6-S+Lt5GgZ+baFonY8y5ag1rQ@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
 <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
 <CAPJVwB=0Th2q03WGJvidKVJwB6-S+Lt5GgZ+baFonY8y5ag1rQ@mail.gmail.com>
Message-ID: <CAEQ_TvdpdNngn45rTHY32PP3O3R8zP4fGseQuH0L3E10xLfjbA@mail.gmail.com>

On Thu, Sep 20, 2018 at 2:33 AM Nathaniel Smith <njs at pobox.com> wrote:

> On Thu, Sep 13, 2018 at 10:30 AM, Stephan Hoyer <shoyer at gmail.com> wrote:
> > I have now drafted these revisions to the NEP to clarify its stance
> around
> > backwards compatibility, and the type of the "types" argument:
> > https://github.com/numpy/numpy/pull/11943
>
> Okay, so this is a pretty substantial change! Before, the NEP's stance
> was "we might change anything, at any time, without any warning",
> which of course makes it easier to accept the NEP (since we can always
> back out), but was also so different from our normal rules that it
> seemed important to make sure people weren't using it without
> realizing. Now it actually makes a commitment: to not regress on what
> functions can be overloaded (though the details might change), and
> commits to an abbreviated-but-nonzero deprecation process when we
> change things. I get the impression that this is closer to what the
> authors were intending in the first place, so that's good! I would
> probably have kept the noisy warning and zero commitments for one
> release anyway, because IMO it's not a big deal and it rarely hurts to
> hedge bets and gather data. But on reflection, I think I am OK with
> this level of commitment if that's what y'all want to go for. (After
> all, it's not really any stronger than NEP 22's high-level plan.) So,
> +0.
>

Nathaniel -- thanks for your critical reviews here, and your
open-mindedness!

I've gone ahead and merged the PR to mark the NEP as accepted. Let's get
started on the fun part of implementation!

Cheers,
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180920/db562c84/attachment.html>

From shoyer at gmail.com  Thu Sep 20 17:33:16 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Thu, 20 Sep 2018 14:33:16 -0700
Subject: [Numpy-discussion] Proposal to accept NEP 22: Duck typing for NumPy
 arrays
Message-ID: <CAEQ_TvfeymkEBOgHOFfxwkdo_E7UABB6sr5+9eEx-fVDQsWQmg@mail.gmail.com>

I propose to accept NEP-22, "Duck typing for NumPy arrays ? high level
overview":
http://www.numpy.org/neps/nep-0022-ndarray-duck-typing-overview.html

This NEP didn't generate much (any?) discussion on the mailing list when
Nathaniel and I sent it out a few months ago. But I still think the
high-level vision makes sense, and it would be nice to mark this
informational NEP as accepted to lay-out a clear vision for how we want to
handle "duck arrays".

One nice thing about informational NEPs is that they don't commit us to any
particular choices, so marking the NEP as is accepted is relatively low
risk :). There are still plenty of details to refine (as we did in NEP-18),
but we can take our time on that.

Cheers,
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180920/1eba647a/attachment.html>

From m.h.vankerkwijk at gmail.com  Thu Sep 20 21:47:38 2018
From: m.h.vankerkwijk at gmail.com (Marten van Kerkwijk)
Date: Thu, 20 Sep 2018 21:47:38 -0400
Subject: [Numpy-discussion] Proposal to accept NEP 22: Duck typing for
 NumPy arrays
In-Reply-To: <CAEQ_TvfeymkEBOgHOFfxwkdo_E7UABB6sr5+9eEx-fVDQsWQmg@mail.gmail.com>
References: <CAEQ_TvfeymkEBOgHOFfxwkdo_E7UABB6sr5+9eEx-fVDQsWQmg@mail.gmail.com>
Message-ID: <CAJNV+9v8t2UG_B7eAAWZD=27LF20+5Y_9JNZ_uWFgKnjdtznkA@mail.gmail.com>

I read the NEP again and think it is a good and useful one (also in
discussing why NEP 16 was not a good idea!).  -- Marten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180920/9c4e6150/attachment.html>

From shoyer at gmail.com  Fri Sep 21 11:54:47 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Fri, 21 Sep 2018 08:54:47 -0700
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAEQ_TvdpdNngn45rTHY32PP3O3R8zP4fGseQuH0L3E10xLfjbA@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
 <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
 <CAPJVwB=0Th2q03WGJvidKVJwB6-S+Lt5GgZ+baFonY8y5ag1rQ@mail.gmail.com>
 <CAEQ_TvdpdNngn45rTHY32PP3O3R8zP4fGseQuH0L3E10xLfjbA@mail.gmail.com>
Message-ID: <CAEQ_TvcWYMDmWHo-ueOxkcgUP3-8-OAnNDOP=43930Pgwn3irg@mail.gmail.com>

On Thu, Sep 20, 2018 at 2:05 PM Stephan Hoyer <shoyer at gmail.com> wrote:

> I've gone ahead and merged the PR to mark the NEP as accepted. Let's get
> started on the fun part of implementation!
>
> Cheers,
> Stephan
>

I have started implementing NEP-18 in a pull request:
https://github.com/numpy/numpy/pull/12005

I propose a multi-step process for implementation:
1. Write a correctly working version of the core __array_function__
machinery in pure Python, adapted from the example implementation in the
NEP.
2. Rewrite bottlenecks in C.
3. Implement overrides for various NumPy functions.

I think the first step is mostly complete, but I'm particularly looking for
help with the second and third steps, which should be able to happen
incrementally and in parallel.

Cheers,
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180921/4ce77765/attachment.html>

From tcaswell at gmail.com  Fri Sep 21 12:08:38 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 21 Sep 2018 12:08:38 -0400
Subject: [Numpy-discussion] Proposal to accept NEP 22: Duck typing for
 NumPy arrays
In-Reply-To: <CAJNV+9v8t2UG_B7eAAWZD=27LF20+5Y_9JNZ_uWFgKnjdtznkA@mail.gmail.com>
References: <CAEQ_TvfeymkEBOgHOFfxwkdo_E7UABB6sr5+9eEx-fVDQsWQmg@mail.gmail.com>
 <CAJNV+9v8t2UG_B7eAAWZD=27LF20+5Y_9JNZ_uWFgKnjdtznkA@mail.gmail.com>
Message-ID: <CAA48SF97EfmwPqnX-dzNB2d1rxUvvPzg1aO1XpN-kjyeqzhA0Q@mail.gmail.com>

I think the NEP does a very good job of capturing the high-level issue
around duck arrays and will serve as a solid base to build future
discussions on.

With my Matplotlib and h5py hats on, I like the discussion about how down
stream projects need to work out their issues with the support of the NumPy
devs.

Tom

On Thu, Sep 20, 2018 at 9:48 PM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

> I read the NEP again and think it is a good and useful one (also in
> discussing why NEP 16 was not a good idea!).  -- Marten
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180921/f2a3b0e5/attachment.html>

From tcaswell at gmail.com  Fri Sep 21 15:25:46 2018
From: tcaswell at gmail.com (Thomas Caswell)
Date: Fri, 21 Sep 2018 15:25:46 -0400
Subject: [Numpy-discussion] Search not working on
 www.numpy.org/devdocs/search.html
In-Reply-To: <d8493a71-106f-8995-7d59-c3e965d9a2b4@gmail.com>
References: <d8493a71-106f-8995-7d59-c3e965d9a2b4@gmail.com>
Message-ID: <CAA48SF9T4bhr1ysJvAaudndbjCmHU13ymxL=YX0aX3HgcD5Kew@mail.gmail.com>

I suspect this is due to issues with sphinx 1.8.0.  Matplotlib also has
this problem (see https://github.com/matplotlib/matplotlib/pull/12183).

Tom

On Mon, Sep 17, 2018 at 10:47 AM Matti Picus <matti.picus at gmail.com> wrote:

> I can enter a search term (say `ndarray`) in
> www.numpy.org/devdocs/search.html, but the result is empty. It worked
> yesterday. My firefox javascript debug console for the remote search says:
>
> jQuery.Deferred exception: Search is not defined
> @http://www.numpy.org/devdocs/search.html?q=ndarray:34:25
> j at http://www.numpy.org/devdocs/_static/jquery.js:2:29997
> g/</k<@http://www.numpy.org/devdocs/_static/jquery.js:2:30313 undefined
>
> If I build the documentation locally, search emits a different error but
> still works:
>
> XML Parsing Error: not well-formed Location:
> file:///.../doc/build/html/searchindex.js Line Number 1, Column 16:
>
> Searching on scipy.org, for instance
>
> https://docs.scipy.org/doc/numpy/search.html?q=ndarray&check_keywords=yes&area=default
> works with no errors on the console
>
> Any hints?
> Matti
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180921/c4247e96/attachment.html>

From ralf.gommers at gmail.com  Sat Sep 22 06:34:46 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Sat, 22 Sep 2018 10:34:46 +0000
Subject: [Numpy-discussion] rescuing missing data documents
In-Reply-To: <1659959e0e8.27ae.acf34a9c767d7bb498a799333be0433e@fastmail.com>
References: <CABL7CQiYYYtFxCTBxFySkerWyxLPhNCFsZaFBYJiYTSy1TtGtA@mail.gmail.com>
 <1659959e0e8.27ae.acf34a9c767d7bb498a799333be0433e@fastmail.com>
Message-ID: <CABL7CQhe-ipSoc_oNSi0GfY7pPhMQnFn=WbsC8OVrHY2WeZ8BA@mail.gmail.com>

On Sun, Sep 2, 2018 at 8:15 AM Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> On September 2, 2018 06:16:36 Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>> I'd like to see the NEPs rescued, and the summary moved from the
>> numpy.org repo (maybe into yet another NEP?). It would be best if the
>> original authors do this, but otherwise I'm happy to do it. Thoughts?
>>
>
> I think this is an excellent suggestion.  A lot of recollections like
> these live in various community members' heads only (some of them no longer
> involved), so I'd love to see that history more carefully reconstructed.
> And the longer we leave it, the harder the detective work becomes!
>

Done in https://github.com/numpy/numpy/pull/12017

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180922/6957fc8e/attachment.html>

From charlesr.harris at gmail.com  Sun Sep 23 08:59:57 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 23 Sep 2018 06:59:57 -0600
Subject: [Numpy-discussion] NumPy 1.15.2 released
Message-ID: <CAB6mnxKC6Ugt3oT_LjC8sxKtwLs0NKYv9iQ_TQ6sNKTsocznAQ@mail.gmail.com>

Hi All,

On behalf of the NumPy team, I am pleased to announce the release of NumPy
1.15.2. This is a bug fix release for bugs and regressions reported
following the 1.15.2 release. The fixes are:

   - the matrix PendingDeprecationWarning is now suppressed in pytest 3.8,
   - the new cached allocations machinery has been fixed to be thread safe,
   - the boolean indexing of subclasses now works correctly,
   - a small memory leak in PyArray_AdaptFlexibleDType has been fixed.

The Python versions supported by this release are 2.7, 3.4-3.7. The wheels
are linked with OpenBLAS v0.3.0, which should fix some of the linalg
problems reported for NumPy 1.14. Wheels for this release can be downloaded
from PyPI <https://pypi.org/project/numpy/1.15.2/>, source archives are
available from Github <https://github.com/numpy/numpy/releases/tag/v1.15.2>

Compatibility Note
==================

The NumPy 1.15.x OS X wheels released on PyPI no longer contain 32-bit
binaries.  That will also be the case in future releases. See
`#11625 <https://github.com/numpy/numpy/issues/11625>`__ for the related
discussion.  Those needing 32-bit support should look elsewhere or build
from source.

Contributors
============

A total of 4 people contributed to this release.  People with a "+" by their
names contributed a patch for the first time.

* Charles Harris
* Julian Taylor
* Marten van Kerkwijk
* Matti Picus

Pull requests merged
====================

A total of 4 pull requests were merged for this release.

* `#11902 <https://github.com/numpy/numpy/pull/11902>`__: BUG: Fix matrix
PendingDeprecationWarning suppression for pytest...
* `#11981 <https://github.com/numpy/numpy/pull/11981>`__: BUG: fix cached
allocations without the GIL for 1.15.x
* `#11982 <https://github.com/numpy/numpy/pull/11982>`__: BUG: fix refcount
leak in PyArray_AdaptFlexibleDType
* `#11992 <https://github.com/numpy/numpy/pull/11992>`__: BUG: Ensure
boolean indexing of subclasses sets base correctly.

Cheers,

Charles Harris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180923/1b7b67ab/attachment.html>

From charlesr.harris at gmail.com  Sun Sep 23 13:36:01 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 23 Sep 2018 11:36:01 -0600
Subject: [Numpy-discussion] Numpy 1.14.6 release
Message-ID: <CAB6mnxJH4R2-O5AX5ZzkCjLu3ntDZR9gczGm302hRCq_yPpd7w@mail.gmail.com>

Hi All,

On behalf of the NumPy team, I am pleased to announce the release of NumPy
1.14.6. This is a bug fix release for bugs and regressions reported
following the 1.14.5 release. The significant fixes are:

   - Fix for behavior change in ``ma.masked_values(shrink=True)``
   - Fix the new cached allocations machinery to be thread safe.

The Python versions supported by this release are 2.7, 3.4-3.7. The wheels
are linked with OpenBLAS v0.3.0, which should fix some of the linalg
problems reported for earlier releases of NumPy 1.14. Wheels for this
release can be downloaded from PyPI <https://pypi.org/project/numpy/1.14.6/>,
source archives are available from Github
<https://github.com/numpy/numpy/releases/tag/v1.14.6>.

Compatibility Note
==================

The NumPy 1.14.6 OS X wheels released on PyPI no longer contain 32-bit
binaries. See #11625 <https://github.com/numpy/numpy/issues/11625> for the
related discussion.  Those needing 32-bit support should look elsewhere or
build from source.

Contributors
============

A total of 4 people contributed to this release.  People with a "+" by their
names contributed a patch for the first time.

   - Charles Harris
   - Eric Wieser
   - Julian Taylor
   - Matti Picus

Pull requests merged
====================

A total of 4 pull requests were merged for this release.

   - #11985: BUG: fix cached allocations without the GIL
   - #11986: BUG: Undo behavior change in ma.masked_values(shrink=True)
   - #11987: BUG: fix refcount leak in PyArray_AdaptFlexibleDType
   - #11995: TST: Add Python 3.7 testing to NumPy 1.14.

Cheers,

Charles Harris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180923/97582770/attachment.html>

From charlesr.harris at gmail.com  Tue Sep 25 11:51:13 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Tue, 25 Sep 2018 09:51:13 -0600
Subject: [Numpy-discussion] PR Cleanup
Message-ID: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>

Hi All,

As usual, the top of the PR stack is getting all the attention. As a start
on cleaning up the old PRs, I'd like to suggest that all the maintainers
look at their (long) pending PRs and decide which they want to keep, close
those they don't want to pursue, and rebase the others. Might also help if
they would post here the PRs that they think we should finish up.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/01a65fc1/attachment.html>

From stefanv at berkeley.edu  Tue Sep 25 12:58:20 2018
From: stefanv at berkeley.edu (Stefan van der Walt)
Date: Tue, 25 Sep 2018 09:58:20 -0700
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
Message-ID: <20180925165820.kjklkg2tglolspcy@carbo>

On Tue, 25 Sep 2018 09:51:13 -0600, Charles R Harris wrote:
> As usual, the top of the PR stack is getting all the attention. As a start
> on cleaning up the old PRs, I'd like to suggest that all the maintainers
> look at their (long) pending PRs and decide which they want to keep, close
> those they don't want to pursue, and rebase the others. Might also help if
> they would post here the PRs that they think we should finish up.

PR 4808 [0] asks whether `np.pad` should have a default mode.  The
proposal is to make the defaul `constant`, with a value of 0.  This is
common in many signal processing applications.

Nathaniel requested that we ask the list before committing.

Best regards,
St?fan


[0] https://github.com/numpy/numpy/pull/4808

From shoyer at gmail.com  Tue Sep 25 13:03:32 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Tue, 25 Sep 2018 10:03:32 -0700
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <20180925165820.kjklkg2tglolspcy@carbo>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <20180925165820.kjklkg2tglolspcy@carbo>
Message-ID: <CAEQ_TvcaUGUOj1LfmvMJ9+SXfeOqkv9k9mqrWZHt2p1ibuhWSg@mail.gmail.com>

On Tue, Sep 25, 2018 at 9:58 AM Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> On Tue, 25 Sep 2018 09:51:13 -0600, Charles R Harris wrote:
> > As usual, the top of the PR stack is getting all the attention. As a
> start
> > on cleaning up the old PRs, I'd like to suggest that all the maintainers
> > look at their (long) pending PRs and decide which they want to keep,
> close
> > those they don't want to pursue, and rebase the others. Might also help
> if
> > they would post here the PRs that they think we should finish up.
>
> PR 4808 [0] asks whether `np.pad` should have a default mode.  The
> proposal is to make the defaul `constant`, with a value of 0.  This is
> common in many signal processing applications.
>
> Nathaniel requested that we ask the list before committing.


+1 for constant padding by zero as the default mode. This is the only
default behavior that I would guess.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/2dd299c4/attachment.html>

From robert.kern at gmail.com  Tue Sep 25 13:07:22 2018
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 25 Sep 2018 10:07:22 -0700
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <20180925165820.kjklkg2tglolspcy@carbo>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <20180925165820.kjklkg2tglolspcy@carbo>
Message-ID: <CAF6FJisewo=gqoUDuyiD1QMA903RJFHcwP15==X5+4Sa8M0Kbg@mail.gmail.com>

On Tue, Sep 25, 2018 at 9:59 AM Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> PR 4808 [0] asks whether `np.pad` should have a default mode.  The
> proposal is to make the defaul `constant`, with a value of 0.  This is
> common in many signal processing applications.
>

+1 for that proposal.

-- 
Robert Kern
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/de69639c/attachment.html>

From charlesr.harris at gmail.com  Tue Sep 25 13:09:44 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Tue, 25 Sep 2018 11:09:44 -0600
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAF6FJisewo=gqoUDuyiD1QMA903RJFHcwP15==X5+4Sa8M0Kbg@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <20180925165820.kjklkg2tglolspcy@carbo>
 <CAF6FJisewo=gqoUDuyiD1QMA903RJFHcwP15==X5+4Sa8M0Kbg@mail.gmail.com>
Message-ID: <CAB6mnx+dGu+c8Um47feNYNr9pVSoJLzHEM3wh-zzd1z6PfZsbw@mail.gmail.com>

On Tue, Sep 25, 2018 at 11:08 AM Robert Kern <robert.kern at gmail.com> wrote:

> On Tue, Sep 25, 2018 at 9:59 AM Stefan van der Walt <stefanv at berkeley.edu>
> wrote:
>
>> PR 4808 [0] asks whether `np.pad` should have a default mode.  The
>> proposal is to make the defaul `constant`, with a value of 0.  This is
>> common in many signal processing applications.
>>
>
> +1 for that proposal.
>
>
+1 also. If this is new behavior, needs a release note.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/f3be17a5/attachment.html>

From pmhobson at gmail.com  Tue Sep 25 13:24:35 2018
From: pmhobson at gmail.com (Paul Hobson)
Date: Tue, 25 Sep 2018 10:24:35 -0700
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <20180925165820.kjklkg2tglolspcy@carbo>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <20180925165820.kjklkg2tglolspcy@carbo>
Message-ID: <CADT3MEB=j7v2Gm_F9=_iCY4h6CFD-MT109LtW1B7tjgVOjZ_WA@mail.gmail.com>

As a user, I found np.pad relatively complex to get up and running (with
all of the string parameters and different formats of the parameters). Some
defaults would be good to just prime the pump, so to speak, when users are
tinkering in e.g., and interactive session.
-Paul

On Tue, Sep 25, 2018 at 9:59 AM Stefan van der Walt <stefanv at berkeley.edu>
wrote:

> On Tue, 25 Sep 2018 09:51:13 -0600, Charles R Harris wrote:
> > As usual, the top of the PR stack is getting all the attention. As a
> start
> > on cleaning up the old PRs, I'd like to suggest that all the maintainers
> > look at their (long) pending PRs and decide which they want to keep,
> close
> > those they don't want to pursue, and rebase the others. Might also help
> if
> > they would post here the PRs that they think we should finish up.
>
> PR 4808 [0] asks whether `np.pad` should have a default mode.  The
> proposal is to make the defaul `constant`, with a value of 0.  This is
> common in many signal processing applications.
>
> Nathaniel requested that we ask the list before committing.
>
> Best regards,
> St?fan
>
>
> [0] https://github.com/numpy/numpy/pull/4808
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/7426c894/attachment-0001.html>

From m.h.vankerkwijk at gmail.com  Tue Sep 25 13:35:19 2018
From: m.h.vankerkwijk at gmail.com (Marten van Kerkwijk)
Date: Tue, 25 Sep 2018 13:35:19 -0400
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
Message-ID: <CAJNV+9sF8kfp9NKqRC1JE1yio+oo_QdvXSN3P-EOxWj7vLVuUg@mail.gmail.com>

Hi Chuck,

Over at astropy we have a bot that sends a warning to PRs that have not
received any commits for 5 months [1] and closes them if nothing happens in
the next month, asking to open an issue instead. Despite my apprehensions,
I found this worked quite well, drawing back attention to forgotten PRs
(and forcing one to consider if they best remain forgotten).

Would there be interest in such a scheme?

All the best,

Marten

p.s. We don't do anything with issues.

[1] Text of the astropy-bot warning:

Hi humans [image: wave] - this pull request hasn't had any new commits for
approximately 5 months. *I plan to close this in a month if the pull
request doesn't have any new commits by then.*

In lieu of a stalled pull request, please consider closing this and open an
issue instead if a reminder is needed to revisit in the future. Maintainers
may also choose to add keep-open label to keep this PR open but it is
discouraged unless absolutely necessary.

If this PR still needs to be reviewed, as an author, you can rebase it to
reset the clock. You may also consider sending a reminder e-mail about it
to the astropy-dev mailing list <http://groups.google.com/group/astropy-dev>
.

*If you believe I commented on this pull request incorrectly, please report
this here <https://github.com/astropy/astropy-bot/issues>.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/bd800270/attachment.html>

From jfoxrabinovitz at gmail.com  Tue Sep 25 14:34:03 2018
From: jfoxrabinovitz at gmail.com (Joseph Fox-Rabinovitz)
Date: Tue, 25 Sep 2018 14:34:03 -0400
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
Message-ID: <CAAa1KPazBgzMU+M7v9=L1kApR-psGK+otyQOruu_xdq45freig@mail.gmail.com>

I think that PRs 7804 and 10855 can be merged (or closed; closure either
way).

7804: ENH: Added atleast_nd
    This has been ready to go for a while. It was deemed superfluous at one
point, but then experienced a revival, which ended up stagnating.
10855: ENH: Adding a count parameter to np.unpackbits
    Has been ready for a while now as well. There is a possible
modification to the interface that may need to be made (not allowing
negative indices), but it's passing everything and good to go as-is, in my
opinion.

Regards,

- Joe


On Tue, Sep 25, 2018 at 11:52 AM Charles R Harris <charlesr.harris at gmail.com>
wrote:

> Hi All,
>
> As usual, the top of the PR stack is getting all the attention. As a start
> on cleaning up the old PRs, I'd like to suggest that all the maintainers
> look at their (long) pending PRs and decide which they want to keep, close
> those they don't want to pursue, and rebase the others. Might also help if
> they would post here the PRs that they think we should finish up.
>
> Chuck
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/6a01f816/attachment.html>

From ralf.gommers at gmail.com  Tue Sep 25 15:12:43 2018
From: ralf.gommers at gmail.com (Ralf Gommers)
Date: Tue, 25 Sep 2018 19:12:43 +0000
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAJNV+9sF8kfp9NKqRC1JE1yio+oo_QdvXSN3P-EOxWj7vLVuUg@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <CAJNV+9sF8kfp9NKqRC1JE1yio+oo_QdvXSN3P-EOxWj7vLVuUg@mail.gmail.com>
Message-ID: <CABL7CQjFuANfHsv1OhNqYFtv+B3nidmwducWorQoF24pbnLzzw@mail.gmail.com>

On Tue, Sep 25, 2018 at 5:35 PM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

> Hi Chuck,
>
> Over at astropy we have a bot that sends a warning to PRs that have not
> received any commits for 5 months [1] and closes them if nothing happens in
> the next month, asking to open an issue instead. Despite my apprehensions,
> I found this worked quite well, drawing back attention to forgotten PRs
> (and forcing one to consider if they best remain forgotten).
>
> Would there be interest in such a scheme?
>

My $2c: I've had this "bot experience" happen to me once (for a pip
contribution), and that left a *really* bad taste. Reading the message
below, that would do the same. E.g. no one bothered to review my PR in 5
months, and now you're asking me to rebase? If that's asked for, them much
better if a human does it.

Other thought: there were a number of people uncomfortable with the pep8
bot we used to have. This one would be more intrusive.

Cheers,
Ralf



>
> All the best,
>
> Marten
>
> p.s. We don't do anything with issues.
>
> [1] Text of the astropy-bot warning:
>
> Hi humans [image: wave] - this pull request hasn't had any new commits
> for approximately 5 months. *I plan to close this in a month if the pull
> request doesn't have any new commits by then.*
>
> In lieu of a stalled pull request, please consider closing this and open
> an issue instead if a reminder is needed to revisit in the future.
> Maintainers may also choose to add keep-open label to keep this PR open
> but it is discouraged unless absolutely necessary.
>
> If this PR still needs to be reviewed, as an author, you can rebase it to
> reset the clock. You may also consider sending a reminder e-mail about it
> to the astropy-dev mailing list
> <http://groups.google.com/group/astropy-dev>.
>
> *If you believe I commented on this pull request incorrectly, please
> report this here <https://github.com/astropy/astropy-bot/issues>.*
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/cd9e0b84/attachment.html>

From allanhaldane at gmail.com  Tue Sep 25 18:55:36 2018
From: allanhaldane at gmail.com (Allan Haldane)
Date: Tue, 25 Sep 2018 18:55:36 -0400
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
Message-ID: <0dbc2995-7dd8-1e6b-dc95-aa5c947a9083@gmail.com>

On 09/25/2018 11:51 AM, Charles R Harris wrote:
> Hi All,
> 
> As usual, the top of the PR stack is getting all the attention. As a
> start on cleaning up the old PRs, I'd like to suggest that all the
> maintainers look at their (long) pending PRs and decide which they want
> to keep, close those they don't want to pursue, and rebase the others.
> Might also help if they would post here the PRs that they think we
> should finish up.

PR 6377 [0] fixes up alignment bugs which cause complex64/128 to be
incorrectly aligned, which in turn causes further bugs. Eg,
"np.dtype('c8').alignment" is 8 but should be 4 on most systems.

The PR is in a finished state, modulo reviews. If anyone has access to
sparc/aarch systems it would be great to test it, though.

Cheers,
Allan


[0] https://github.com/numpy/numpy/pull/6377

From jni.soma at gmail.com  Tue Sep 25 20:00:36 2018
From: jni.soma at gmail.com (Juan Nunez-Iglesias)
Date: Wed, 26 Sep 2018 10:00:36 +1000
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CABL7CQjFuANfHsv1OhNqYFtv+B3nidmwducWorQoF24pbnLzzw@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <CAJNV+9sF8kfp9NKqRC1JE1yio+oo_QdvXSN3P-EOxWj7vLVuUg@mail.gmail.com>
 <CABL7CQjFuANfHsv1OhNqYFtv+B3nidmwducWorQoF24pbnLzzw@mail.gmail.com>
Message-ID: <8BF3E6CF-CB4D-41A2-9117-35F54AE6F21F@gmail.com>


> On 26 Sep 2018, at 5:12 am, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> My $2c: I've had this "bot experience" happen to me once (for a pip contribution), and that left a *really* bad taste.

I?m going to second Ralf?s comments here. These bots are a great idea if your number one goal is to reduce the number of open PRs at the cost of everything else ? including happy contributors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180926/6fd0bd44/attachment.html>

From harrigan.matthew at gmail.com  Tue Sep 25 20:08:32 2018
From: harrigan.matthew at gmail.com (Matthew Harrigan)
Date: Tue, 25 Sep 2018 20:08:32 -0400
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <0dbc2995-7dd8-1e6b-dc95-aa5c947a9083@gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <0dbc2995-7dd8-1e6b-dc95-aa5c947a9083@gmail.com>
Message-ID: <CAOfRF=h7AVHUm2azppQ71UqEx+rALpATyadJNKxrBXfVDKZwbQ@mail.gmail.com>

PR 8528 <https://github.com/numpy/numpy/pull/8528> adds logical gufuncs
such as " all equal".  The functionality has been mentioned quite a few
times on this list. Many implementations are in the PR and they are decent
IMHO.  The hard part is the API and current ufunc code.  Initially I
thought they would be top level functions, ie np.all_equal, but there
appears to be general consensus that they should be ufunc methods, ie
np.equal.all.  Its not clear to me at least how that should be done.
Adding all, any, and first methods to all ufuncs seems bad.  Some sort of
monkeypatch hack also seems bad.  Rewriting the ufunc code to make the
methods specific to each ufunc, likely breaking the abi/api, is a big
effort.  Suggestions welcome.  Thank you.

On Tue, Sep 25, 2018 at 6:56 PM Allan Haldane <allanhaldane at gmail.com>
wrote:

> On 09/25/2018 11:51 AM, Charles R Harris wrote:
> > Hi All,
> >
> > As usual, the top of the PR stack is getting all the attention. As a
> > start on cleaning up the old PRs, I'd like to suggest that all the
> > maintainers look at their (long) pending PRs and decide which they want
> > to keep, close those they don't want to pursue, and rebase the others.
> > Might also help if they would post here the PRs that they think we
> > should finish up.
>
> PR 6377 [0] fixes up alignment bugs which cause complex64/128 to be
> incorrectly aligned, which in turn causes further bugs. Eg,
> "np.dtype('c8').alignment" is 8 but should be 4 on most systems.
>
> The PR is in a finished state, modulo reviews. If anyone has access to
> sparc/aarch systems it would be great to test it, though.
>
> Cheers,
> Allan
>
>
> [0] https://github.com/numpy/numpy/pull/6377
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/8779a7e5/attachment.html>

From harrigan.matthew at gmail.com  Tue Sep 25 20:16:36 2018
From: harrigan.matthew at gmail.com (Matthew Harrigan)
Date: Tue, 25 Sep 2018 20:16:36 -0400
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <8BF3E6CF-CB4D-41A2-9117-35F54AE6F21F@gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <CAJNV+9sF8kfp9NKqRC1JE1yio+oo_QdvXSN3P-EOxWj7vLVuUg@mail.gmail.com>
 <CABL7CQjFuANfHsv1OhNqYFtv+B3nidmwducWorQoF24pbnLzzw@mail.gmail.com>
 <8BF3E6CF-CB4D-41A2-9117-35F54AE6F21F@gmail.com>
Message-ID: <CAOfRF=is2i8LyQhjroy4iEnKEvfVrKLvFXi4JRq1k4XkQs1zLg@mail.gmail.com>

Would it be possible to have an opt-in for that bot?

On Tue, Sep 25, 2018 at 8:01 PM Juan Nunez-Iglesias <jni.soma at gmail.com>
wrote:

>
> On 26 Sep 2018, at 5:12 am, Ralf Gommers <ralf.gommers at gmail.com> wrote:
> My $2c: I've had this "bot experience" happen to me once (for a pip
> contribution), and that left a *really* bad taste.
>
>
> I?m going to second Ralf?s comments here. These bots are a great idea if
> your number one goal is to reduce the number of open PRs at the cost of
> everything else ? including happy contributors.
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/3bb02345/attachment.html>

From charlesr.harris at gmail.com  Tue Sep 25 20:17:33 2018
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Tue, 25 Sep 2018 18:17:33 -0600
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAOfRF=h7AVHUm2azppQ71UqEx+rALpATyadJNKxrBXfVDKZwbQ@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <0dbc2995-7dd8-1e6b-dc95-aa5c947a9083@gmail.com>
 <CAOfRF=h7AVHUm2azppQ71UqEx+rALpATyadJNKxrBXfVDKZwbQ@mail.gmail.com>
Message-ID: <CAB6mnxLLKw8J=HMCFJRFaM6LvdOj2P+2YskY3KL1_25PHw_xnQ@mail.gmail.com>

On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan <harrigan.matthew at gmail.com>
wrote:

> PR 8528 <https://github.com/numpy/numpy/pull/8528> adds logical gufuncs
> such as " all equal".  The functionality has been mentioned quite a few
> times on this list. Many implementations are in the PR and they are decent
> IMHO.  The hard part is the API and current ufunc code.  Initially I
> thought they would be top level functions, ie np.all_equal, but there
> appears to be general consensus that they should be ufunc methods, ie
> np.equal.all.  Its not clear to me at least how that should be done.
> Adding all, any, and first methods to all ufuncs seems bad.  Some sort of
> monkeypatch hack also seems bad.  Rewriting the ufunc code to make the
> methods specific to each ufunc, likely breaking the abi/api, is a big
> effort.  Suggestions welcome.  Thank you.
>

Hmm, I'm not a big fan of ufunc methods, I think there are too many :) I
suppose the argument in favor is decreasing the number of function names,
which also has its proponents. What is the gain here in making them stand
alone functions, more speed, possible SIMD speedups, etc.?

<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/1fbfd206/attachment-0001.html>

From harrigan.matthew at gmail.com  Tue Sep 25 20:24:52 2018
From: harrigan.matthew at gmail.com (Matthew Harrigan)
Date: Tue, 25 Sep 2018 20:24:52 -0400
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAB6mnxLLKw8J=HMCFJRFaM6LvdOj2P+2YskY3KL1_25PHw_xnQ@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <0dbc2995-7dd8-1e6b-dc95-aa5c947a9083@gmail.com>
 <CAOfRF=h7AVHUm2azppQ71UqEx+rALpATyadJNKxrBXfVDKZwbQ@mail.gmail.com>
 <CAB6mnxLLKw8J=HMCFJRFaM6LvdOj2P+2YskY3KL1_25PHw_xnQ@mail.gmail.com>
Message-ID: <CAOfRF=h3gE59XuV1eEOrfYZk_dz7p9VQP9XSzJK3oVg0UD=BeA@mail.gmail.com>

Speed, and to a lesser extent memory.  The biggest advantage is it allows
short circuiting with ridiculous speedups for certain cases.  It also
removes intermediate arrays/bandwidth.  There is some SIMD speedup but
thats a relatively small benefit.

On Tue, Sep 25, 2018 at 8:18 PM Charles R Harris <charlesr.harris at gmail.com>
wrote:

>
>
> On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan <
> harrigan.matthew at gmail.com> wrote:
>
>> PR 8528 <https://github.com/numpy/numpy/pull/8528> adds logical gufuncs
>> such as " all equal".  The functionality has been mentioned quite a few
>> times on this list. Many implementations are in the PR and they are decent
>> IMHO.  The hard part is the API and current ufunc code.  Initially I
>> thought they would be top level functions, ie np.all_equal, but there
>> appears to be general consensus that they should be ufunc methods, ie
>> np.equal.all.  Its not clear to me at least how that should be done.
>> Adding all, any, and first methods to all ufuncs seems bad.  Some sort of
>> monkeypatch hack also seems bad.  Rewriting the ufunc code to make the
>> methods specific to each ufunc, likely breaking the abi/api, is a big
>> effort.  Suggestions welcome.  Thank you.
>>
>
> Hmm, I'm not a big fan of ufunc methods, I think there are too many :) I
> suppose the argument in favor is decreasing the number of function names,
> which also has its proponents. What is the gain here in making them stand
> alone functions, more speed, possible SIMD speedups, etc.?
>
> <snip>
>
> Chuck
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/1137cefc/attachment.html>

From m.h.vankerkwijk at gmail.com  Tue Sep 25 21:24:11 2018
From: m.h.vankerkwijk at gmail.com (Marten van Kerkwijk)
Date: Tue, 25 Sep 2018 21:24:11 -0400
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAOfRF=h3gE59XuV1eEOrfYZk_dz7p9VQP9XSzJK3oVg0UD=BeA@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <0dbc2995-7dd8-1e6b-dc95-aa5c947a9083@gmail.com>
 <CAOfRF=h7AVHUm2azppQ71UqEx+rALpATyadJNKxrBXfVDKZwbQ@mail.gmail.com>
 <CAB6mnxLLKw8J=HMCFJRFaM6LvdOj2P+2YskY3KL1_25PHw_xnQ@mail.gmail.com>
 <CAOfRF=h3gE59XuV1eEOrfYZk_dz7p9VQP9XSzJK3oVg0UD=BeA@mail.gmail.com>
Message-ID: <CAJNV+9u=HATaWTcAd30JgVhGb2XV18VFZab8QkhV1SaiVB=EOg@mail.gmail.com>

Hi Matthew,

With the decision not to support broadcasting in ufunc signatures, I think
a ufunc route for generally useful all_equal has become hard at the present
time. So, as it it seems the only useful route is indeed a separate
function... (perhaps in the end we can use stackable ufuncs, which operate
in chunks - I have a prototype but it doesn't do reductions yet, so not
directly relevant).

All the best,

Marten

On Tue, Sep 25, 2018 at 8:25 PM Matthew Harrigan <harrigan.matthew at gmail.com>
wrote:

> Speed, and to a lesser extent memory.  The biggest advantage is it allows
> short circuiting with ridiculous speedups for certain cases.  It also
> removes intermediate arrays/bandwidth.  There is some SIMD speedup but
> thats a relatively small benefit.
>
> On Tue, Sep 25, 2018 at 8:18 PM Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>>
>> On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan <
>> harrigan.matthew at gmail.com> wrote:
>>
>>> PR 8528 <https://github.com/numpy/numpy/pull/8528> adds logical gufuncs
>>> such as " all equal".  The functionality has been mentioned quite a few
>>> times on this list. Many implementations are in the PR and they are decent
>>> IMHO.  The hard part is the API and current ufunc code.  Initially I
>>> thought they would be top level functions, ie np.all_equal, but there
>>> appears to be general consensus that they should be ufunc methods, ie
>>> np.equal.all.  Its not clear to me at least how that should be done.
>>> Adding all, any, and first methods to all ufuncs seems bad.  Some sort of
>>> monkeypatch hack also seems bad.  Rewriting the ufunc code to make the
>>> methods specific to each ufunc, likely breaking the abi/api, is a big
>>> effort.  Suggestions welcome.  Thank you.
>>>
>>
>> Hmm, I'm not a big fan of ufunc methods, I think there are too many :) I
>> suppose the argument in favor is decreasing the number of function names,
>> which also has its proponents. What is the gain here in making them stand
>> alone functions, more speed, possible SIMD speedups, etc.?
>>
>> <snip>
>>
>> Chuck
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180925/8484e8c2/attachment.html>

From davidmenhur at gmail.com  Wed Sep 26 08:05:42 2018
From: davidmenhur at gmail.com (=?UTF-8?B?RGHPgGlk?=)
Date: Wed, 26 Sep 2018 14:05:42 +0200
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CABL7CQjFuANfHsv1OhNqYFtv+B3nidmwducWorQoF24pbnLzzw@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <CAJNV+9sF8kfp9NKqRC1JE1yio+oo_QdvXSN3P-EOxWj7vLVuUg@mail.gmail.com>
 <CABL7CQjFuANfHsv1OhNqYFtv+B3nidmwducWorQoF24pbnLzzw@mail.gmail.com>
Message-ID: <CAJhcF=1SuBM1tSNTwEUtY4seUh7cBue+3u3AKVECK_14dgRJ-A@mail.gmail.com>

On Tue, 25 Sep 2018 at 21:14, Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Tue, Sep 25, 2018 at 5:35 PM Marten van Kerkwijk <
> m.h.vankerkwijk at gmail.com> wrote:
>
>> Hi Chuck,
>>
>> Over at astropy we have a bot that sends a warning to PRs that have not
>> received any commits for 5 months [1] and closes them if nothing happens in
>> the next month, asking to open an issue instead. Despite my apprehensions,
>> I found this worked quite well, drawing back attention to forgotten PRs
>> (and forcing one to consider if they best remain forgotten).
>>
>> Would there be interest in such a scheme?
>>
>
> My $2c: I've had this "bot experience" happen to me once (for a pip
> contribution), and that left a *really* bad taste. Reading the message
> below, that would do the same. E.g. no one bothered to review my PR in 5
> months, and now you're asking me to rebase? If that's asked for, them much
> better if a human does it.
>
> Other thought: there were a number of people uncomfortable with the pep8
> bot we used to have. This one would be more intrusive.
>
> Cheers,
> Ralf
>
>
I think Tensorflow does it better. Their butler-bot nags the core developer
assigned to the PR or issue if the report isn't marked as awaiting
information or suggestions pending. I think this is much nicer for external
contributors. On the other hand, TF has paid staff to take care of this,
here it would be up to you guys if you feel up to being nagged by robots.

Exact text:

Nagging Assignee @rohan100jain <https://github.com/rohan100jain>: It has
been 14 days with no activity and this issue has an assignee. Please update
the label and/or status accordingly.

https://github.com/tensorflow/tensorflow/issues/22180
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180926/b0dfb1e1/attachment-0001.html>

From jorisvandenbossche at gmail.com  Wed Sep 26 12:18:05 2018
From: jorisvandenbossche at gmail.com (Joris Van den Bossche)
Date: Wed, 26 Sep 2018 18:18:05 +0200
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CAEQ_TvcWYMDmWHo-ueOxkcgUP3-8-OAnNDOP=43930Pgwn3irg@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
 <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
 <CAPJVwB=0Th2q03WGJvidKVJwB6-S+Lt5GgZ+baFonY8y5ag1rQ@mail.gmail.com>
 <CAEQ_TvdpdNngn45rTHY32PP3O3R8zP4fGseQuH0L3E10xLfjbA@mail.gmail.com>
 <CAEQ_TvcWYMDmWHo-ueOxkcgUP3-8-OAnNDOP=43930Pgwn3irg@mail.gmail.com>
Message-ID: <CALQtMBbSpA5xG+XVQZwpOCRAPKKP2iT0yaUTgJkYoWVoPyc5Lg@mail.gmail.com>

Hi all,

I have small question for clarification regarding some reducing numpy
functions like np.sum, np.mean, etc, i.e. functions that now work on other
array-like objects by checking if they have 'sum', 'mean', etc method and
if so, "dispatch" to the method.
Those functions are several times mentioned as examples in the text of the
NEP, so although the NEP does not list the functions that will use the
__array_function__ protocol explicitly, I assume that those functions will
probably be in that list. But I wanted to check if that assumption is
correct.

Is it the intent that the functions that now dispatch to object methods
will be updated to use the protocol instead? (probably keeping to
method-dispatch as second try for backwards compatibility)

Not something urgent, but I was just wondering that when reading the NEP,
as this is something that would be useful for pandas (where we now need to
do some gymnastics to deal with arguments passed by numpy to those methods
that we don't support).

Joris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180926/b6d7cf4f/attachment.html>

From shoyer at gmail.com  Wed Sep 26 15:59:35 2018
From: shoyer at gmail.com (Stephan Hoyer)
Date: Wed, 26 Sep 2018 12:59:35 -0700
Subject: [Numpy-discussion] Proposal to accept NEP-18,
 __array_function__ protocol
In-Reply-To: <CALQtMBbSpA5xG+XVQZwpOCRAPKKP2iT0yaUTgJkYoWVoPyc5Lg@mail.gmail.com>
References: <CAEQ_TveGsnJ6k_azUwqn-p1WZPvJSASwX=GXBNRLDQ9uMjQYiA@mail.gmail.com>
 <CAB6mnx+Q-sw0pUFW4zB+43cz7qpusN7qEr-Qg63L5=nheW3Y-g@mail.gmail.com>
 <CAEQ_TvdyFjYRyVcdYdwPk5Cv=qfVUMLpM9drVoGo6Ud8ibvVJw@mail.gmail.com>
 <CAPJVwB=0Th2q03WGJvidKVJwB6-S+Lt5GgZ+baFonY8y5ag1rQ@mail.gmail.com>
 <CAEQ_TvdpdNngn45rTHY32PP3O3R8zP4fGseQuH0L3E10xLfjbA@mail.gmail.com>
 <CAEQ_TvcWYMDmWHo-ueOxkcgUP3-8-OAnNDOP=43930Pgwn3irg@mail.gmail.com>
 <CALQtMBbSpA5xG+XVQZwpOCRAPKKP2iT0yaUTgJkYoWVoPyc5Lg@mail.gmail.com>
Message-ID: <CAEQ_TvdAoz_yOWmhOtf8K5GXmoPDWUbtEmamw=3gX7JEvBnD0g@mail.gmail.com>

On Wed, Sep 26, 2018 at 9:19 AM Joris Van den Bossche <
jorisvandenbossche at gmail.com> wrote:

> Hi all,
>
> I have small question for clarification regarding some reducing numpy
> functions like np.sum, np.mean, etc, i.e. functions that now work on
> other array-like objects by checking if they have 'sum', 'mean', etc method
> and if so, "dispatch" to the method.
> Those functions are several times mentioned as examples in the text of the
> NEP, so although the NEP does not list the functions that will use the
> __array_function__ protocol explicitly, I assume that those functions
> will probably be in that list. But I wanted to check if that assumption is
> correct.
>
> Is it the intent that the functions that now dispatch to object methods
> will be updated to use the protocol instead? (probably keeping to
> method-dispatch as second try for backwards compatibility)
>

Hi Joris,

Yes, this is my exact intent. Eventually, we might remove/deprecate
automatically calling methods with the same name (due to how error prone
this is), but that is a long way in the future if ever.

Keep in mind that the current version of the NEP may not be a good fit for
pandas, because it requires overriding *all* NumPy functions. See this
section of the NEP for details:
http://www.numpy.org/neps/nep-0018-array-function-protocol.html#coercion-to-a-numpy-array-as-a-catch-all-fallback

Cheers,
Stephan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180926/dc827137/attachment.html>

From nussbaum at uni-mainz.de  Thu Sep 27 04:17:56 2018
From: nussbaum at uni-mainz.de (=?UTF-8?Q?Andreas_Nu=C3=9Fbaumer?=)
Date: Thu, 27 Sep 2018 10:17:56 +0200
Subject: [Numpy-discussion] scaling of the covariance matrix in np.polyfit
Message-ID: <CANdXcwG9FS2x+KGrdz=-co=TG3NOqKyOHtd5w=OSqoMg6NZjCg@mail.gmail.com>

Hi,

a while ago I tried to figure out what holds back the PR 11197. Could
anyone have a look? Thanks for your help.

Andreas

From harrigan.matthew at gmail.com  Thu Sep 27 13:48:17 2018
From: harrigan.matthew at gmail.com (Matthew Harrigan)
Date: Thu, 27 Sep 2018 13:48:17 -0400
Subject: [Numpy-discussion] PR Cleanup
In-Reply-To: <CAJNV+9u=HATaWTcAd30JgVhGb2XV18VFZab8QkhV1SaiVB=EOg@mail.gmail.com>
References: <CAB6mnxJTMxVPZndGzZ6eF-+bCLZ8gkgN0vbRxTWysJztDVEY+g@mail.gmail.com>
 <0dbc2995-7dd8-1e6b-dc95-aa5c947a9083@gmail.com>
 <CAOfRF=h7AVHUm2azppQ71UqEx+rALpATyadJNKxrBXfVDKZwbQ@mail.gmail.com>
 <CAB6mnxLLKw8J=HMCFJRFaM6LvdOj2P+2YskY3KL1_25PHw_xnQ@mail.gmail.com>
 <CAOfRF=h3gE59XuV1eEOrfYZk_dz7p9VQP9XSzJK3oVg0UD=BeA@mail.gmail.com>
 <CAJNV+9u=HATaWTcAd30JgVhGb2XV18VFZab8QkhV1SaiVB=EOg@mail.gmail.com>
Message-ID: <CAOfRF=j9URdPD_AWQnHb0vu9S0cx32L6uZNsesP0NyeZ2i0MOA@mail.gmail.com>

Marten,
I think a ufunc route is pretty straightforward assuming there is a higher
level function.  It would be something like this:

def wrapper_for_all_equal(x, y):
    return np.private_ufunc_all_equal(*np.broadcast_arrays(x, y))

The largest outstanding issue I see are what the api should be.  There was
concern about adding too many functions to the already crowded numpy
namespace.

On Tue, Sep 25, 2018 at 9:25 PM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

> Hi Matthew,
>
> With the decision not to support broadcasting in ufunc signatures, I think
> a ufunc route for generally useful all_equal has become hard at the present
> time. So, as it it seems the only useful route is indeed a separate
> function... (perhaps in the end we can use stackable ufuncs, which operate
> in chunks - I have a prototype but it doesn't do reductions yet, so not
> directly relevant).
>
> All the best,
>
> Marten
>
> On Tue, Sep 25, 2018 at 8:25 PM Matthew Harrigan <
> harrigan.matthew at gmail.com> wrote:
>
>> Speed, and to a lesser extent memory.  The biggest advantage is it allows
>> short circuiting with ridiculous speedups for certain cases.  It also
>> removes intermediate arrays/bandwidth.  There is some SIMD speedup but
>> thats a relatively small benefit.
>>
>> On Tue, Sep 25, 2018 at 8:18 PM Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, Sep 25, 2018 at 6:09 PM Matthew Harrigan <
>>> harrigan.matthew at gmail.com> wrote:
>>>
>>>> PR 8528 <https://github.com/numpy/numpy/pull/8528> adds logical
>>>> gufuncs such as " all equal".  The functionality has been mentioned quite a
>>>> few times on this list. Many implementations are in the PR and they are
>>>> decent IMHO.  The hard part is the API and current ufunc code.  Initially I
>>>> thought they would be top level functions, ie np.all_equal, but there
>>>> appears to be general consensus that they should be ufunc methods, ie
>>>> np.equal.all.  Its not clear to me at least how that should be done.
>>>> Adding all, any, and first methods to all ufuncs seems bad.  Some sort of
>>>> monkeypatch hack also seems bad.  Rewriting the ufunc code to make the
>>>> methods specific to each ufunc, likely breaking the abi/api, is a big
>>>> effort.  Suggestions welcome.  Thank you.
>>>>
>>>
>>> Hmm, I'm not a big fan of ufunc methods, I think there are too many :) I
>>> suppose the argument in favor is decreasing the number of function names,
>>> which also has its proponents. What is the gain here in making them stand
>>> alone functions, more speed, possible SIMD speedups, etc.?
>>>
>>> <snip>
>>>
>>> Chuck
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180927/35befb5d/attachment.html>