Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

2021-07-04 Thread Ralf Gommers
Let's see if we can finalize this.



On Thu, Jun 24, 2021 at 9:23 PM Stefan van der Walt 
wrote:

> On Thu, Jun 24, 2021, at 01:03, Ralf Gommers wrote:
>
> For this one, I'd say it kinda looks like we do need one, so then  let's
> just add one and be done with it, rather than inventing odd patterns like
> tacking enum members onto an existing function.
>
>
> There are two arguments on the table that resonate with me:
>
> 1. Chuck argues that the current `copy=False` behavior (which, in fact,
> means copy-if-needed) is nonsensical and should be fixed.
> 2. Ralf argues that strings are ultimately the interface we'd like to see.
>
> To achieve (1), we would need a deprecation cycle.  During that
> deprecation cycle, we would need to provide a way to continue providing
> 'copy-if-needed' behavior.  This can be achieved either with an enum or by
> accepting strings.
>
> Stephan argues that accepting strings will be harmful to new code running
> on old versions of NumPy.  I would still like to get a sense of how often
> this happens, or if that is a hit we are willing to take.  If we decide
> that the concern is a significant one, then we would have to go the enum
> route, at least for a while.  However, I see no compelling reason to have
> that enum live in the top-level namespace though: it is for relatively
> advanced use, and it will be temporary.
>
> If we take the enum route, how do we get to (2)?  We add a type check for
> a few releases and raise an error on string arguments (or, alternatively,
> handle 'always'/'never'/'if_needed' without advertising that
> functionality).  Then, once we switch to string arguments, users will get
> an error (for old NumPy) or it will work as expected (for new NumPy).
>

What Stephan said in his last email seems right, just switch to strings at
some point (probably after 3 years or so), and stop recommending the enum.


> I didn't think so originally, but I suppose we are in NEP territory now.
>

I don't think so. We basically arrived at the solution, and there's a PR
that is mostly done too. This really isn't that complicated that we should
require a NEP.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion


Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

2021-07-04 Thread Stefan van der Walt
On Sun, Jul 4, 2021, at 13:00, Ralf Gommers wrote:
> I don't think so. We basically arrived at the solution, and there's a PR that 
> is mostly done too. This really isn't that complicated that we should require 
> a NEP.

Personally, I don't like np.CopyMode in the main namespace. If we can agree to 
stash it somewhere else, and tentatively aim to move to strings at point X in 
time for consistency with the rest of the API, I have no issue with going 
ahead. 

Stéfan 
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion


[Numpy-discussion] [ANN] Software job opportunity in clean energy

2021-07-04 Thread Dr. Mark Alexander Mikofski PhD
Dear Pythonistas,

DNV Energy USA is looking for an experienced software engineer to help
accelerate the renewable energy transition. Do you know any software
engineers interested in clean energy?
Would you mind sharing the following link with your network?

https://www.linkedin.com/jobs/view/2574048777

Thank you!
Mark A. Mikofski
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion