On Fri, Jul 27, 2018 at 12:02 PM, Stephan Hoyer wrote:
> On Tue, Jul 24, 2018 at 5:38 PM Ralf Gommers
> wrote:
>
>> This is very developer-centric view. We have lots of users and also lots
>> of no-longer-active contributors. The needs, interests and previous work
>> put into NumPy of those
On Tue, Jul 24, 2018 at 5:38 PM Ralf Gommers wrote:
> This is very developer-centric view. We have lots of users and also lots
> of no-longer-active contributors. The needs, interests and previous work
> put into NumPy of those groups of people matter.
>
Yes, I suppose it is :).
I tend to view
On Tue, Jul 24, 2018 at 8:07 PM, Nathaniel Smith wrote:
> On Sun, Jul 22, 2018 at 12:28 PM, Ralf Gommers
> wrote:
> > On Sat, Jul 21, 2018 at 7:15 PM, Nathaniel Smith wrote:
> >> Speaking of examples: I hate to say this because in general I think
> >> using examples is a great idea. But... I
On Sun, Jul 22, 2018 at 12:28 PM, Ralf Gommers wrote:
> On Sat, Jul 21, 2018 at 7:15 PM, Nathaniel Smith wrote:
>> Speaking of examples: I hate to say this because in general I think
>> using examples is a great idea. But... I think you should delete most
>> of these examples. The problem is
On Mon, Jul 23, 2018 at 11:46 AM, Stephan Hoyer wrote:
> On Sun, Jul 22, 2018 at 12:28 PM Ralf Gommers
> wrote:
>
>> Then, I think it's not unreasonable to draw a couple of hard lines. For
>> example, removing complete submodules like linalg or random has ended up on
>> some draft brainstorm
On 23. Jul 2018 at 19:46, Stephan Hoyer wrote:
On Sat, Jul 21, 2018 at 6:40 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> But I think the subclassing section is somewhat misleading in suggesting
> `ndarray` is not well designed to be subclassed. At least, for neither my
> work
On Mon, Jul 23, 2018 at 1:43 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
>
>> Rather, we might state that "At some point in the future, the NumPy
>> development team may no longer interested in maintaining workarounds for
>> specific subclasses, because other interfaces for
On Mon, Jul 23, 2018 at 1:45 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> That sentence I think covers it very well. Subclasses can and should be
> expected to evolve along with numpy, and if that means some numpy-version
> dependent parts, so be it (we have those now...).
>
My
>
>
> Rather, we might state that "At some point in the future, the NumPy
> development team may no longer interested in maintaining workarounds for
> specific subclasses, because other interfaces for extending NumPy are
> believed to be more maintainable/preferred."
>
> That sentence I think
On Sun, Jul 22, 2018 at 12:28 PM Ralf Gommers
wrote:
> Then, I think it's not unreasonable to draw a couple of hard lines. For
> example, removing complete submodules like linalg or random has ended up on
> some draft brainstorm roadmap list because someone (no idea who) put it
> there after a
On Sat, Jul 21, 2018 at 6:40 PM Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> But I think the subclassing section is somewhat misleading in suggesting
> `ndarray` is not well designed to be subclassed. At least, for neither my
> work on Quantity nor that on MaskedArray, I've found
Hi Ralf,
>> Overall, this looks good. But I think the subclassing section is somewhat
>> misleading in suggesting `ndarray` is not well designed to be subclassed.
>> At least, for neither my work on Quantity nor that on MaskedArray, I've
>> found that the design of `ndarray` itself was a
On Sat, Jul 21, 2018 at 7:15 PM, Nathaniel Smith wrote:
> On Sat, Jul 21, 2018 at 4:48 PM, Ralf Gommers
> wrote:
> > Hi all,
> >
> > Here is a first draft of a NEP on backwards compatibility and deprecation
> > policy. This I think mostly formalized what we've done for the last
> couple
> > of
On Sat, Jul 21, 2018 at 7:06 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Maybe as a concrete example of something that has been discussed, for
> which your proposed text makes (I think) clear what should or should not be
> done:
>
> Many of us hate that `np.array`
Hi Marten,
Thanks for the thoughtful reply.
On Sat, Jul 21, 2018 at 6:39 PM, Marten van Kerkwijk <
m.h.vankerkw...@gmail.com> wrote:
> Hi Ralf,
>
> Overall, this looks good. But I think the subclassing section is somewhat
> misleading in suggesting `ndarray` is not well designed to be
On Sat, Jul 21, 2018 at 5:46 PM, Hameer Abbasi
wrote:
> The possibility of another major version change (possibly the same one)
> where we re-write all portions that were agreed upon (via NEPs) to be
> re-written, with a longer LTS release (3 years? 5?).
>
> I’m thinking this one could be similar
On Sat, Jul 21, 2018 at 4:48 PM, Ralf Gommers wrote:
> Hi all,
>
> Here is a first draft of a NEP on backwards compatibility and deprecation
> policy. This I think mostly formalized what we've done for the last couple
> of years, however I'm sure opinions and wish lists will differ here.
Oh
Agreed that changes better be gradual, and that we do not have the manpower
to do otherwise (I was slightly shocked to see that my 94 commits in the
last two years make me the fourth most prolific contributor in that
period... And that is from the couple of hours a week I use while
procrastinating
Hi Ralf,
Maybe as a concrete example of something that has been discussed, for which
your proposed text makes (I think) clear what should or should not be done:
Many of us hate that `np.array` (like, sadly, many other numpy parts)
auto-converts anything not obviously array-like to dtype=object,
>
>- We enforce good practices in our code. For example, we will
> explicitly disallow subclassing from ndarray, we get rid of scalars, we
> fix
> the type system.
>
>
> Given my other reply, probably no surprise that I strongly disagree with
the idea of disallowing subclasses.
On Sat, Jul 21, 2018 at 5:46 PM, Hameer Abbasi
wrote:
> Hello,
>
> Very well written article! It takes a lot of important things into
> account. I think a number of things should be mentioned, if only in the
> alternatives:
>
>- One major version number change, with lots of “major version
Hello,
Very well written article! It takes a lot of important things into account.
I think a number of things should be mentioned, if only in the alternatives:
- One major version number change, with lots of “major version change”
deprecations grouped into it, along with an LTS release.
22 matches
Mail list logo
