As per discussed, I've opened a PR
https://github.com/numpy/numpy/pull/17093 attempting to clarify some
of the writing and to follow the NEP Template. As suggested in the
template, please find below the top part of NEP-35 (up to and
including the Backward Compatibility section). Please feel free to
On Fri, Aug 14, 2020 at 12:23 PM Peter Andreas Entschev
wrote:
> Hi all,
>
> This thread has IMO drifted very far from its original purpose, due to
> that I decided to start a new thread specifically for the general NEP
> procedure discussed, please check your mail for "NEP Procedure Discussion"
Hi all,
This thread has IMO drifted very far from its original purpose, due to that
I decided to start a new thread specifically for the general NEP procedure
discussed, please check your mail for "NEP Procedure Discussion" subject.
On the topic of this thread, I'll try to rewrite NEP-35 to make
Hello everyone again!
A few clarifications about my proposal of external peer review:
- Yes, all this work is public and announced on the mailing list. However, I
don’t think there’s a single person in this discussion or even this whole
ecosystem that does not have a more immediately-pressing a
On Thu, Aug 13, 2020 at 5:22 AM Ralf Gommers wrote:
> Thanks for raising these concerns Ilhan and Juan, and for answering Peter.
> Let me give my perspective as well.
>
> To start with, this is not specifically about Peter's NEP and PR. NEP 35
> simply follows the pattern set by previous PRs, and
Yes, the underlying gory details should be spelled out of course but if it
is also modifying/adding to API then it is best to sound the horn and
invite zombies to take a stab at it. Often people arrive with interesting
use-cases that you wouldn't have thought about.
And I am very familiar with the
On Thu, 2020-08-13 at 15:47 +0200, Peter Andreas Entschev wrote:
> > We adapted the NEP template [6] several times last year to try and
> > improve this. And specified in there as well that NEP content set
> > to the mailing list should only contain the sections: Abstract,
> > Motivation and Scope,
Ralf,
I know none of it is a criticism of my work or directly of anybody
else's work. I was just making a couple of general points (or
questions really):
1. What is accepted as a reasonably clear NEP? It seems to point that
a NEP _must_ follow the Template
2. Should the NEP Template be followed a
Ilhan,
Thanks, that does clarify things.
I think the main point -- and correct me here if I'm still wrong -- is
that we want the NEP to have some very clear example of when/why/how
to use it, preferably as early in the text as possible, maybe just
below the Abstract, in a Motivation and Scope sec
On Thu, Aug 13, 2020 at 2:47 PM Peter Andreas Entschev
wrote:
> > We adapted the NEP template [6] several times last year to try and
> improve this. And specified in there as well that NEP content set to the
> mailing list should only contain the sections: Abstract, Motivation and
> Scope, Usage
> We adapted the NEP template [6] several times last year to try and improve
> this. And specified in there as well that NEP content set to the mailing list
> should only contain the sections: Abstract, Motivation and Scope, Usage and
> Impact, and Backwards compatibility. This to ensure we full
To maybe lighten up the discussion a bit and to make my outsider confusion
more tangible, let me start by apologizing for diving head first without
weighing the past luggage :-) I always forget how much effort goes into
these things and for outsiders like me, it's a matter of dipping the finger
and
Thanks for raising these concerns Ilhan and Juan, and for answering Peter.
Let me give my perspective as well.
To start with, this is not specifically about Peter's NEP and PR. NEP 35
simply follows the pattern set by previous PRs, and given its tight scope
is less difficult to understand than oth
> I am not sure adding a new keyword to an already confusing function is the
> right thing to do.
Could you clarify what is the confusing function in question?
> This is already a very (I mean extremely very) easy keyword name to confuse
> with ones_like, zeros_like and by its nature any other
I’ve generally been on the “let the NumPy devs worry about it” side of things,
but I do agree with Ilhan that `like=` is confusing and `typeof=` would be a
much more appropriate name for that parameter.
I do think library writers are NumPy users and so I wouldn’t really make that
distinction, t
For what is worth, as a potential consumer in SciPy, it really doesn't say
anything (both in NEP and the PR) about how the regular users of NumPy will
benefit from this. If only and only 3rd parties are going to benefit from
it, I am not sure adding a new keyword to an already confusing function is
On Mon, Aug 10, 2020 at 8:37 PM Sebastian Berg
wrote:
> On Mon, 2020-08-10 at 17:35 +0200, Hameer Abbasi wrote:
> > Hi,
> >
> > We should have a higher-bandwidth meeting/communication for all
> > stakeholders, and particularly some library authors, to see what
> > would be good for them.
>
I'm n
On Mon, 2020-08-10 at 17:35 +0200, Hameer Abbasi wrote:
> Hi,
>
> We should have a higher-bandwidth meeting/communication for all
> stakeholders, and particularly some library authors, to see what
> would be good for them.
>
> We should definitely have language in the NEP that says it won’t be
>
Hi,
We should have a higher-bandwidth meeting/communication for all stakeholders,
and particularly some library authors, to see what would be good for them.
We should definitely have language in the NEP that says it won’t be in a
release unless the NEP is accepted.
Best regards,
Hameer Abbasi
Hi all,
as a heads up that Peter Entschev has a PR open to add `like=` to
most array creation functions, my current plan is to merge it soon as a
preliminary API and bring it up again before the actual release (in a few
months). This allows overriding for array-likes, e.g. it will allow:
20 matches
Mail list logo
