[Numpy-discussion] NEP Procedure Discussion

[Peter Andreas Entschev]

Hi all,

During the discussion about NEP-35, there have been lots of
discussions around the NEP process itself. In the interest of allowing
people who are mostly interested in this discussion and to avoid
drifting so much off-topic in that thread, I'm starting this new
thread to discuss the NEP procedure.

A few questions that have been raised so far:

- Is the NEP Template [1] a guideline to be strictly followed or a
suggestion for authors?
- Who should decide when a NEP is sufficiently clear?
- Should a NEP PR be merged at all until it's sufficiently clear or
should it only be merged even in Draft state only after it's
sufficiently clear?
- What parts of the NEP are necessary to be clear for everyone? Just
Abstract? Motivation and Scope? Everything, including the real
technical details of implementation?
- Would it be possible to have proof-readers -- preferably people who
are not at all involved in the NEP's topic?

Please feel free to comment on that and add any major points I might
have missed.

Best,
Peter

[1] https://github.com/numpy/numpy/blob/master/doc/neps/nep-template.rst
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Experimental `like=` attribute for array creation functions

[Peter Andreas Entschev]

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 it more
accessible and ping back here once I have a PR for that. Is there anything
else that's pressing here? If there is and I missed/forgot about it, please
let me know.

Best,
Peter

On Fri, Aug 14, 2020 at 5:00 AM Juan Nunez-Iglesias 
wrote:

> 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 and also virtually
> infinite to-do list, so it’s unreasonable to expect that generally they
> would do more than glance at the stuff in the mailing list. In the peer
> review analogy, the mailing list is like the arXiv or Biorxiv stream — yep,
> anyone can see the stuff on there and comment, but most people just don’t
> have the time or attention to grab onto that. The only reason I stopped to
> comment here is Sebastian’s “Imma merge, YOLO!”, which had me raising my
> eyebrows real high. 😂 Especially for something that would expand the NumPy
> API!
>
> - So, my proposal is that there needs to be an *editor* of NEPs who takes
> responsibility, once they are themselves satisfied with the NEP, for
> seeking out external reviewers and pinging them individually and asking
> them if they would be ok to review.
>
> - A good friend who does screenwriting once told me, “don’t use all your
> proofreaders at once”. You want to get feedback, improve things, then
> feedback from a *totally independent* new person who can see the document
> with fresh eyes.
>
> Obviously, all of the above slows things down. But “alone we go fast,
> together we go far”. The point of a NEP is to document critical decisions
> for the long term health of the project. If the documentation is
> insufficient, it defeats the whole purpose. Might as well just implement
> stuff and skip the whole NEP process. (Side note: Stephan, I for one would
> definitely appreciate an update to existing NEPs if there’s obvious ways
> they can be improved!)
>
> I do think that NEP templates should be strict, and I don’t think that is
> incompatible with plain, jargon-free text. The NEP template and guidelines
> should specify that, and that the motivation should be understandable by a
> casual NumPy user — the kind described by Ilhan, for whom bare NumPy
> actually meets all their needs. Maybe they’ve also used PyTorch but they’ve
> never really had cause to mix them or write a program that worked with both
> kinds of arrays.
>
> Ditto for backwards compatibility — everyone should be clear when their
> existing code is going to be broken. Actually NEP18 broke so much of my
> code, but its Backward compatibility section basically says all good!
> https://numpy.org/neps/nep-0018-array-function-protocol.html#backward-compatibility
>
>
> Anywho, as always, none of this is criticism to work done — I thank you
> all, and am eternally grateful for all the hard work everyone is doing to
> keep the ecosystem from fragmenting. I’m just hoping that this discussion
> can improve the process going forward!
>
> And, yes, apologies to Peter, I know from repeated personal experience how
> frustrating it can be to have last-minute drive-by objections after months
> of consensus building! But I think in the end every time that happened the
> end result was better — I hope the same is true here! And yes, I’ll
> reiterate Ralf’s point: my concerns are about the NEP process itself rather
> than this one. I’ll summarise my proposal:
>
> - strict NEP template. NEPs with missing sections will not be accepted.
> - sections Abstract, Motivation, and Backwards Compatibility should be
> understandable at a high level by casual users with ~zero background on the
> topic
> - enforce the above with at least two independent rounds of coordinated
> peer review.
>
> Thank you,
>
> Juan.
>
> On 14 Aug 2020, at 5:29 am, Stephan Hoyer  wrote:
>
> 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 given its tight scope
>> is less difficult to understand than other NEPs on such technical topics.
>> Peter has done a lot of things right, and is close to the finish line.
>>
>>
>> On Thu, Aug 13, 2020 at 12:02 PM Peter Andreas Entschev <
>> pe...@entschev.com> wrote:
>>
>>>
>>> > I think, arriving to an agreement would be much faster if there is an
>>> executive summary of who this is intended for and what the 

Re: [Numpy-discussion] NEP Procedure Discussion

[Ilhan Polat]

Also, not to be a complete slacker, I'd like to add to this list;

- How can I help as an external lib maintainer?
- Do you even want us to get involved before the final draft? Or wait until
internal discussion finishes?




On Fri, Aug 14, 2020 at 1:23 PM Peter Andreas Entschev 
wrote:

> Hi all,
>
> During the discussion about NEP-35, there have been lots of
> discussions around the NEP process itself. In the interest of allowing
> people who are mostly interested in this discussion and to avoid
> drifting so much off-topic in that thread, I'm starting this new
> thread to discuss the NEP procedure.
>
> A few questions that have been raised so far:
>
> - Is the NEP Template [1] a guideline to be strictly followed or a
> suggestion for authors?
> - Who should decide when a NEP is sufficiently clear?
> - Should a NEP PR be merged at all until it's sufficiently clear or
> should it only be merged even in Draft state only after it's
> sufficiently clear?
> - What parts of the NEP are necessary to be clear for everyone? Just
> Abstract? Motivation and Scope? Everything, including the real
> technical details of implementation?
> - Would it be possible to have proof-readers -- preferably people who
> are not at all involved in the NEP's topic?
>
> Please feel free to comment on that and add any major points I might
> have missed.
>
> Best,
> Peter
>
> [1] https://github.com/numpy/numpy/blob/master/doc/neps/nep-template.rst
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] NEP Procedure Discussion

[Adrin]

Somewhat relevant, this is the discussion around the same topic we've been
having in scikit-learn:
https://github.com/scikit-learn/enhancement_proposals/pull/30

On Fri, Aug 14, 2020 at 2:36 PM Ilhan Polat  wrote:

> Also, not to be a complete slacker, I'd like to add to this list;
>
> - How can I help as an external lib maintainer?
> - Do you even want us to get involved before the final draft? Or wait
> until internal discussion finishes?
>
>
>
>
> On Fri, Aug 14, 2020 at 1:23 PM Peter Andreas Entschev 
> wrote:
>
>> Hi all,
>>
>> During the discussion about NEP-35, there have been lots of
>> discussions around the NEP process itself. In the interest of allowing
>> people who are mostly interested in this discussion and to avoid
>> drifting so much off-topic in that thread, I'm starting this new
>> thread to discuss the NEP procedure.
>>
>> A few questions that have been raised so far:
>>
>> - Is the NEP Template [1] a guideline to be strictly followed or a
>> suggestion for authors?
>> - Who should decide when a NEP is sufficiently clear?
>> - Should a NEP PR be merged at all until it's sufficiently clear or
>> should it only be merged even in Draft state only after it's
>> sufficiently clear?
>> - What parts of the NEP are necessary to be clear for everyone? Just
>> Abstract? Motivation and Scope? Everything, including the real
>> technical details of implementation?
>> - Would it be possible to have proof-readers -- preferably people who
>> are not at all involved in the NEP's topic?
>>
>> Please feel free to comment on that and add any major points I might
>> have missed.
>>
>> Best,
>> Peter
>>
>> [1] https://github.com/numpy/numpy/blob/master/doc/neps/nep-template.rst
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] Use of booleans in slices

[Sebastian Berg]

This is because slicing with a boolean has just no confusing meaning I
can think of [1].  NumPy even used to reject it, but there seems no
reason to add maintenance/code complexity (i.e. duplicate code from
Python already provides) to reject bools. There used to be a reason to
using `__index__()` in slices, because Python did not. But now Python
caught up.

- Sebastian

[1] I have never seen anyone index with a bool, and I have no
conception of what `arr[masked:not_masked]` would mean.
There is not a small step from `arr[True]` to `arr[True:]`.



On Thu, 2020-08-13 at 15:14 -0600, Aaron Meurer wrote:
> I noticed that np.bool_.__index__() gives a DeprecationWarning
> 
> > > > np.bool_(True).__index__()
> __main__:1: DeprecationWarning: In future, it will be an error for
> 'np.bool_' scalars to be interpreted as an index
> 1
> 
> This is good, because booleans don't actually act like integers in
> indexing contexts. However, raw Python bools also allow __index__()
> 
> > > > True.__index__()
> 1
> 
> A consequence of this is that NumPy slices allow booleans, as long as
> they are the Python type (if you use the NumPy bool_ type you get the
> deprecation warning).
> 
> > > > a = np.arange(10)
> > > > a[True:]
> array([1, 2, 3, 4, 5, 6, 7, 8, 9])
> 
> Should this behavior also be considered deprecated? Presumably
> deprecating bool.__index__() in Python is a no-go, but it could be
> deprecated in NumPy contexts (in the pure Python collections,
> booleans
> don't have a special indexing meaning anyway).
> 
> Interestingly, places that use a shape don't allow booleans (I guess
> they don't necessarily use __index__()?)
> 
> > > > np.empty((True,))
> Traceback (most recent call last):
>   File "", line 1, in 
> TypeError: an integer is required
> 
> Aaron Meurer
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> 



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Documentation Team meeting - Monday August 17

[Melissa Mendonça]

Hi all!

This is a reminder that our next Documentation Team meeting will be on *Monday,
August 17* at 3PM UTC**. If you wish to join on Zoom, you need to use this
link

https://zoom.us/j/420005230

Here's the permanent hackmd document with the meeting notes (still being
updated in the next few days!):

https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg


Hope to see you around!

** You can click this link to get the correct time at your timezone:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentation+Team+Meeting&iso=20200817T15&p1=1440&ah=1


*** You can add the NumPy community calendar to your google calendar by
clicking this link:
https://calendar.google.com/calendar/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20

- Melissa
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion