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 grou
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 th
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 scop
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 roa
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
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 extendi
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 ho
>
>
> 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 cover
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 si
On Sun, Jul 22, 2018 at 12:28 PM Ralf Gommers
wrote:
> In particular, I'd like every deprecation message to say "this deprecated
> feature will be removed by release X.Y.0". At the moment we don't do that,
> so if users see a message they don't know if a removal will happen next
> year, in the f
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 that
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 problem.
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 y
On Sat, Jul 21, 2018 at 7:25 PM, Nathaniel Smith wrote:
> 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 LT
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` (l
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 subclasse
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 *awes
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, a
>
>- 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. But
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 problem. Instead, it
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 cha
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.
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.
Pull request: https://github.com/numpy/numpy/pull/11596
Rendered versi
26 matches
Mail list logo
