> Our API is huge. A simple count:
> main namespace: 600
> fft: 30
> linalg: 30
> random: 60
> ndarray: 70
> lib: 20
> lib.npyio: 35
> etc. (many more ill-thought out but not clearly private submodules)
>
>
I would perhaps start with ndarray itself. Quite a lot seems superfluous
Shapes:
- need:
> > In this respect, I think an excellent place to start might be
>> > something you are planning already anyway: update the user
>> > documentation
>> >
>>
>> I would include tests as well. Rather than hammer out a full standard
>> based on extensive discussions and negotiations, I
On Sat, Jun 1, 2019 at 1:05 PM Ralf Gommers wrote:
> I think this is potentially useful, but *far* more prescriptive and detailed
> than I had in mind. Both you and Nathaniel seem to have not understood what I
> mean by "out of scope", so I think that's my fault in not being explicit
> enough.
On Sat, Jun 1, 2019 at 10:05 PM Ralf Gommers wrote:
>
> I think this is potentially useful, but *far* more prescriptive and
> detailed than I had in mind. Both you and Nathaniel seem to have not
> understood what I mean by "out of scope", so I think that's my fault in not
> being explicit
On Sat, Jun 1, 2019 at 10:32 PM Nathaniel Smith wrote:
> On Sat, Jun 1, 2019, 09:13 Ralf Gommers wrote:
>
>>
>>
>> On Sat, Jun 1, 2019 at 11:32 AM Nathaniel Smith wrote:
>>
>>> It's possible I'm not getting what you're thinking, but from what you
>>> describe in your email I think it's a bad
On Sat, Jun 1, 2019, 09:13 Ralf Gommers wrote:
>
>
> On Sat, Jun 1, 2019 at 11:32 AM Nathaniel Smith wrote:
>
>> It's possible I'm not getting what you're thinking, but from what you
>> describe in your email I think it's a bad idea.
>>
>
> Hi Nathaniel, I think you are indeed not getting what
On Sat, Jun 1, 2019 at 8:46 PM Matti Picus wrote:
> On 1/6/19 7:31 pm, Charles R Harris wrote:
> > I generally agree with this. The most useful aspect of this exercise
> > is likely to be clarifying NumPy for its own developers, and maybe
> > offering a guide to future simplification. Trying to
On Sat, Jun 1, 2019, 05:23 Hameer Abbasi wrote:
> I think this hits the crux of the issue... There *is* a huge coordination
> problem. Users want to move their code from NumPy to Sparse or Dask all the
> time, but it’s not trivial to do. And libraries like sparse and Dask want
> to follow a
On 1/6/19 7:31 pm, Charles R Harris wrote:
I generally agree with this. The most useful aspect of this exercise
is likely to be clarifying NumPy for its own developers, and maybe
offering a guide to future simplification. Trying to put something
together that everyone agrees to as an official
On Sat, Jun 1, 2019 at 10:12 AM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Despite sharing Nathaniel's doubts about the ease of defining the numpy
> API and the likelihood of people actually sticking to a limited subset of
> what numpy exposes, I quite like the actual
On Sat, Jun 1, 2019 at 6:12 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Despite sharing Nathaniel's doubts about the ease of defining the numpy
> API and the likelihood of people actually sticking to a limited subset of
> what numpy exposes, I quite like the actual
On Sat, Jun 1, 2019 at 11:32 AM Nathaniel Smith wrote:
> It's possible I'm not getting what you're thinking, but from what you
> describe in your email I think it's a bad idea.
>
Hi Nathaniel, I think you are indeed not getting what I meant and are just
responding to the word "standard".
I'll
Hi Ralf,
Despite sharing Nathaniel's doubts about the ease of defining the numpy API
and the likelihood of people actually sticking to a limited subset of what
numpy exposes, I quite like the actual things you propose to do!
But my liking it is for reasons that are different from your stated
> On Jun 1, 2019, at 4:17 AM, Ralf Gommers wrote:
>
> Hi all,
>
> I have an idea that I've discussed with a few people in person, and the
> feedback has generally been positive. So I'd like to bring it up here, to get
> a sense of if this is going to fly. Note that this is NOT a proposal at
I think this hits the crux of the issue... There is a huge coordination
problem. Users want to move their code from NumPy to Sparse or Dask all the
time, but it’s not trivial to do. And libraries like sparse and Dask want to
follow a standard (or at least hoped there was one) before they
It's possible I'm not getting what you're thinking, but from what you
describe in your email I think it's a bad idea.
Standards take a tremendous amount of work (no really, an absurdly
massively huge amount of work, more than you can imagine if you
haven't done it). And they don't do what people
Hi all,
I have an idea that I've discussed with a few people in person, and the
feedback has generally been positive. So I'd like to bring it up here, to
get a sense of if this is going to fly. Note that this is NOT a proposal at
this point.
Idea in five words: define a NumPy API standard
17 matches
Mail list logo
