Re: [Numpy-discussion] NumPy-Discussion Digest, Vol 163, Issue 23
On Sat, Apr 25, 2020 at 4:50 PM
Send NumPy-Discussion mailing list submissions to numpy-discussion@python.org
To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman/listinfo/numpy-discussion or, via email, send a message with subject or body 'help' to numpy-discussion-request@python.org
You can reach the person managing the list at numpy-discussion-owner@python.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of NumPy-Discussion digest..." Today's Topics:
1. Re: Feelings about type aliases in NumPy (Sebastian Berg) 2. beginner introduction to group (Tina Oberoi) 3. Re: beginner introduction to group (Robert Kern) 4. Re: Feelings about type aliases in NumPy (Stephan Hoyer) 5. Re: Feelings about type aliases in NumPy (Kevin Sheppard)
---------- Forwarded message ---------- From: Sebastian Berg
To: numpy-discussion@python.org Cc: Bcc: Date: Fri, 24 Apr 2020 13:29:59 -0500 Subject: Re: [Numpy-discussion] Feelings about type aliases in NumPy On Fri, 2020-04-24 at 11:10 -0700, Stefan van der Walt wrote: On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote:
But, Stephan pointed out that it might be confusing to users for objects to only exist at typing time, so we came around to the question of whether people are open to the idea of including the type aliases in NumPy itself. Ralf's concrete proposal was to make a module numpy.types (or maybe numpy.typing) to hold the aliases so that they don't pollute the top-level namespace. The module would initially contain the types
That sounds very sensible. Having types available with NumPy should also encourage their use, especially if we can add some documentation around it.
I agree, I might have a small tendency for `numpy.types` if we ever find any usage other than direct typing that may be the better name?
Out of curiousity, I guess `ArrayLike` would be an ABC that a downstream project can register with?
- Sebastian
Stéfan _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
---------- Forwarded message ---------- From: Tina Oberoi
To: numpy-discussion@python.org Cc: Bcc: Date: Sat, 25 Apr 2020 10:30:38 +0530 Subject: [Numpy-discussion] beginner introduction to group Hi Everyone, I am new to contributing to numpy. I have read the contributors guide and done with the set-up. Hope to make some good contributions and also to connect with all you great people in the numpy community. Any suggestions and tips are always welcome. Thanks and Regards
Welcome, Tina! -- Inessa Pawson
---------- Forwarded message ---------- From: Robert Kern
To: Discussion of Numerical Python Cc: Bcc: Date: Sat, 25 Apr 2020 01:59:57 -0400 Subject: Re: [Numpy-discussion] beginner introduction to group On Sat, Apr 25, 2020 at 1:02 AM Tina Oberoi wrote: Hi Everyone, I am new to contributing to numpy. I have read the contributors guide and done with the set-up. Hope to make some good contributions and also to connect with all you great people in the numpy community. Any suggestions and tips are always welcome.
Welcome! Do you have an idea what you would like to work on?
-- Robert Kern
---------- Forwarded message ---------- From: Stephan Hoyer
To: Discussion of Numerical Python Cc: Bcc: Date: Fri, 24 Apr 2020 23:40:20 -0700 Subject: Re: [Numpy-discussion] Feelings about type aliases in NumPy On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg < sebastian@sipsolutions.net> wrote:
On Fri, 2020-04-24 at 11:10 -0700, Stefan van der Walt wrote:
On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote:
But, Stephan pointed out that it might be confusing to users for objects to only exist at typing time, so we came around to the question of whether people are open to the idea of including the type aliases in NumPy itself. Ralf's concrete proposal was to make a module numpy.types (or maybe numpy.typing) to hold the aliases so that they don't pollute the top-level namespace. The module would initially contain the types
That sounds very sensible. Having types available with NumPy should also encourage their use, especially if we can add some documentation around it.
I agree, I might have a small tendency for `numpy.types` if we ever find any usage other than direct typing that may be the better name?
Unless we anticipate adding a long list of type aliases (more than the three suggested so far), I would lean towards adding ArrayLike to the top level NumPy namespace as np.ArrayLike.
Type annotations are becoming an increasingly core part of modern Python code. We should make it easy to appropriately type check functions that act on NumPy arrays, and a top level np.ArrayLike is definitely more convenient than np.types.ArrayLike.
Out of curiousity, I guess `ArrayLike` would be an ABC that a
downstream project can register with?
ArrayLike will be a typing Protocol, automatically recognizing attributes like __array__ to indicate that something can be cast to an array.
- Sebastian
Stéfan _______________________________________________ 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
---------- Forwarded message ---------- From: Kevin Sheppard
To: Discussion of Numerical Python Cc: Bcc: Date: Sat, 25 Apr 2020 07:49:58 +0100 Subject: Re: [Numpy-discussion] Feelings about type aliases in NumPy Typing is for library developers more than end users. I would also worry that putting it into the top level might discourage other typing classes since it is more difficult to add to the top level than to a lower level module. np.typing seems very clear to me. On Sat, Apr 25, 2020, 07:41 Stephan Hoyer
wrote: On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg < sebastian@sipsolutions.net> wrote:
On Fri, 2020-04-24 at 11:10 -0700, Stefan van der Walt wrote:
On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote:
But, Stephan pointed out that it might be confusing to users for objects to only exist at typing time, so we came around to the question of whether people are open to the idea of including the type aliases in NumPy itself. Ralf's concrete proposal was to make a module numpy.types (or maybe numpy.typing) to hold the aliases so that they don't pollute the top-level namespace. The module would initially contain the types
That sounds very sensible. Having types available with NumPy should also encourage their use, especially if we can add some documentation around it.
I agree, I might have a small tendency for `numpy.types` if we ever find any usage other than direct typing that may be the better name?
Unless we anticipate adding a long list of type aliases (more than the three suggested so far), I would lean towards adding ArrayLike to the top level NumPy namespace as np.ArrayLike.
Type annotations are becoming an increasingly core part of modern Python code. We should make it easy to appropriately type check functions that act on NumPy arrays, and a top level np.ArrayLike is definitely more convenient than np.types.ArrayLike.
Out of curiousity, I guess `ArrayLike` would be an ABC that a
downstream project can register with?
ArrayLike will be a typing Protocol, automatically recognizing attributes like __array__ to indicate that something can be cast to an array.
- Sebastian
Stéfan _______________________________________________ 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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
participants (1)
-
Inessa Pawson