On Sun, Nov 1, 2020 at 7:47 PM Stefan van der Walt
wrote:
> On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote:
> > I also misunderstood the purpose of the NEP. I assumed it was
> > intended to encourage projects to drop old versions of Python. Other
> > people have viewed the NEP similarly:
I also feel the NEP is very useful since it helps downstream to drop older versions relatively early. I’ve found this very useful in projects that have less maintenance bandwidth. Kevin From: Jarrod MillmanSent: Monday, November 2, 2020 2:56 AMTo: Discussion of Numerical PythonSubject: Re:
On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote:
> I also misunderstood the purpose of the NEP. I assumed it was
> intended to encourage projects to drop old versions of Python. Other
> people have viewed the NEP similarly:
> https://github.com/networkx/networkx/issues/4027
Of all the
I also misunderstood the purpose of the NEP. I assumed it was
intended to encourage projects to drop old versions of Python. Other
people have viewed the NEP similarly:
https://github.com/networkx/networkx/issues/4027
If the intention of the NEP is to specify that projects not drop old
version
NetworkX is currently planning to support 3.6 for our coming 2.6
release (dec 2020) and 3.0 release (early 2021). We had originally
thought about following NEP 29. But I assumed it had been abandoned,
since neither NumPy nor SciPy dropped Python 3.6 on Jun 23, 2020.
NetworkX is likely to
pandas has already dropped 3.6 support in our coming 1.2 release (nov 2020);
1.1.x supports 3.6
> On Nov 1, 2020, at 9:04 PM, Charles R Harris
> wrote:
>
>
>
>
> On Sun, Nov 1, 2020 at 6:48 PM Mark Harfouche
> wrote:
>>>
>>> Do you think the proposal is not in compliance? There is no
On Sun, Nov 1, 2020 at 6:48 PM Mark Harfouche
wrote:
>
>> Do you think the proposal is not in compliance? There is no requirement
>> that we drop anything more than 42 months old, it is just recommended. The
>> change in the Python release cycle has created some difficulty. With the
>> yearly
>
>
> Do you think the proposal is not in compliance? There is no requirement
> that we drop anything more than 42 months old, it is just recommended. The
> change in the Python release cycle has created some difficulty. With the
> yearly cycle, 4 python yearly releases will cover 3-4 years, which
This is in the pending PR. Hopefully out in 1.20.
Kevin
On Sun, Nov 1, 2020, 23:55 Currurant wrote:
> I realized that neither numpy.random.multinomial nor rng.multinomial has
> the
> ability to draw from different multinomial distributions at the same time
> like what MATLAB mnrnd() does
I realized that neither numpy.random.multinomial nor rng.multinomial has the
ability to draw from different multinomial distributions at the same time
like what MATLAB mnrnd() does here:
https://www.mathworks.com/help/stats/mnrnd.html
Also, I have asked this question on StackOverFlow:
I know it seems silly, but would an amendment to NEP29 be reasonable?
Many downstream packages look to numpy to understand what versions should
be supported and NEP29 gave some good guidance.
That said, if it is worth ignoring, or revisiting, some clarity on how to
apply NEP29 given recent
> Just to speak for myself, I don't think the precise choice matters very much.
> There are arguments for consistency both ways.
I agree with this. In the absence of strong theoretical considerations
I'd fall back to a practical one-we can make ndarray generic over
dtype _right now_, while for
12 matches
Mail list logo
