Feelings about type aliases in NumPy

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Feelings about type aliases in NumPy

Joshua Wilson
Hey everyone,

Over in numpy-stubs we've been working on typing "array like":

https://github.com/numpy/numpy-stubs/pull/66

It would be nice if the type were public so that downstream projects
could use it (e.g. it would be very helpful in SciPy). Originally the
plan was to only make it publicly available at typing time and not
runtime, which would mean that no changes to NumPy are necessary; see

https://github.com/numpy/numpy-stubs/pull/66#issuecomment-618784833

for more information on how that works.

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

- ArrayLike
- DtypeLike
- (maybe) ShapeLike

Note that we would not need to make changes to NumPy right away;
instead it would probably be done when numpy-stubs is merged into
NumPy itself.

What do people think?

- Josh
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Feelings about type aliases in NumPy

Stefan van der Walt
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.

Stéfan
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Feelings about type aliases in NumPy

Sebastian Berg
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
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Feelings about type aliases in NumPy

Stephan Hoyer-2


On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg <[hidden email]> 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
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Feelings about type aliases in NumPy

bashtage
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 <[hidden email]> wrote:


On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg <[hidden email]> 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
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Feelings about type aliases in NumPy

Ilhan Polat
I agree that parking all these in a secondary namespace sounds a better option, can't say that I feel for the word "typing" though. There are already too many type, dtype, ctypeslib etc. Maybe we can go for a bit more distant name like "numpy.annotations" or whatever. 

On Sat, Apr 25, 2020 at 8:51 AM Kevin Sheppard <[hidden email]> wrote:
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 <[hidden email]> wrote:


On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg <[hidden email]> 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
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Feelings about type aliases in NumPy

Joshua Wilson
To try and add some more data points to the conversation:

> Maybe we can go for a bit more distant name like "numpy.annotations" or whatever.

Interestingly this was proposed independently here:

https://github.com/numpy/numpy-stubs/pull/66#issuecomment-619131274

Related to that, Ralf was opposed to numpy.typing because it would
shadow a stdlib module name:

https://github.com/numpy/numpy-stubs/pull/66#issuecomment-619123629

But, types is _also_ a stdlib module name. Maybe the above points give
some extra weight to "numpy.annotations"?

> Unless we anticipate adding a long list of type aliases (more than the three suggested so far)

While working on some types in SciPy here:

https://github.com/scipy/scipy/pull/11936#discussion_r415280894

we ran into the issue of typing things that are "integer types" or
"floating types". For the time being we just inlined a definition like
Union[float, np.floating], but conceivably we would want to unify
those definitions somewhere instead of redefining them in every
project. (Note that existing types like SupportsInt etc. were not what
we wanted.) This perhaps suggests that the ultimate number of type
aliases might be larger than we initially thought.

On Sun, Apr 26, 2020 at 6:25 AM Ilhan Polat <[hidden email]> wrote:

>
> I agree that parking all these in a secondary namespace sounds a better option, can't say that I feel for the word "typing" though. There are already too many type, dtype, ctypeslib etc. Maybe we can go for a bit more distant name like "numpy.annotations" or whatever.
>
> On Sat, Apr 25, 2020 at 8:51 AM Kevin Sheppard <[hidden email]> wrote:
>>
>> 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 <[hidden email]> wrote:
>>>
>>>
>>>
>>> On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg <[hidden email]> 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
>>>> > [hidden email]
>>>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>>>>
>>>>
>>>> _______________________________________________
>>>> NumPy-Discussion mailing list
>>>> [hidden email]
>>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> [hidden email]
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> [hidden email]
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Feelings about type aliases in NumPy

Ilhan Polat
> Interestingly this was proposed independently here:

Wow apologies for missing the entire thread about it and the noise.


On Sun, Apr 26, 2020 at 11:19 PM Joshua Wilson <[hidden email]> wrote:
To try and add some more data points to the conversation:

> Maybe we can go for a bit more distant name like "numpy.annotations" or whatever.

Interestingly this was proposed independently here:

https://github.com/numpy/numpy-stubs/pull/66#issuecomment-619131274

Related to that, Ralf was opposed to numpy.typing because it would
shadow a stdlib module name:

https://github.com/numpy/numpy-stubs/pull/66#issuecomment-619123629

But, types is _also_ a stdlib module name. Maybe the above points give
some extra weight to "numpy.annotations"?

> Unless we anticipate adding a long list of type aliases (more than the three suggested so far)

While working on some types in SciPy here:

https://github.com/scipy/scipy/pull/11936#discussion_r415280894

we ran into the issue of typing things that are "integer types" or
"floating types". For the time being we just inlined a definition like
Union[float, np.floating], but conceivably we would want to unify
those definitions somewhere instead of redefining them in every
project. (Note that existing types like SupportsInt etc. were not what
we wanted.) This perhaps suggests that the ultimate number of type
aliases might be larger than we initially thought.

On Sun, Apr 26, 2020 at 6:25 AM Ilhan Polat <[hidden email]> wrote:
>
> I agree that parking all these in a secondary namespace sounds a better option, can't say that I feel for the word "typing" though. There are already too many type, dtype, ctypeslib etc. Maybe we can go for a bit more distant name like "numpy.annotations" or whatever.
>
> On Sat, Apr 25, 2020 at 8:51 AM Kevin Sheppard <[hidden email]> wrote:
>>
>> 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 <[hidden email]> wrote:
>>>
>>>
>>>
>>> On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg <[hidden email]> 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
>>>> > [hidden email]
>>>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>>>>
>>>>
>>>> _______________________________________________
>>>> NumPy-Discussion mailing list
>>>> [hidden email]
>>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> [hidden email]
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> [hidden email]
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Feelings about type aliases in NumPy

Joshua Wilson
Following some additional discussion on the PR (see comments after
https://github.com/numpy/numpy-stubs/pull/66#issuecomment-620139434),
the proposed path forward is:

- Add the module `numpy.typing` to the type stubs only for now
- Initially it will contain types for ArrayLike and DtypeLike
- When the stubs are merged into NumPy, add the `numpy.typing` module
to NumPy itself.

Any further objections?

On Mon, Apr 27, 2020 at 10:50 AM Ilhan Polat <[hidden email]> wrote:

>
> > Interestingly this was proposed independently here:
>
> Wow apologies for missing the entire thread about it and the noise.
>
>
> On Sun, Apr 26, 2020 at 11:19 PM Joshua Wilson <[hidden email]> wrote:
>>
>> To try and add some more data points to the conversation:
>>
>> > Maybe we can go for a bit more distant name like "numpy.annotations" or whatever.
>>
>> Interestingly this was proposed independently here:
>>
>> https://github.com/numpy/numpy-stubs/pull/66#issuecomment-619131274
>>
>> Related to that, Ralf was opposed to numpy.typing because it would
>> shadow a stdlib module name:
>>
>> https://github.com/numpy/numpy-stubs/pull/66#issuecomment-619123629
>>
>> But, types is _also_ a stdlib module name. Maybe the above points give
>> some extra weight to "numpy.annotations"?
>>
>> > Unless we anticipate adding a long list of type aliases (more than the three suggested so far)
>>
>> While working on some types in SciPy here:
>>
>> https://github.com/scipy/scipy/pull/11936#discussion_r415280894
>>
>> we ran into the issue of typing things that are "integer types" or
>> "floating types". For the time being we just inlined a definition like
>> Union[float, np.floating], but conceivably we would want to unify
>> those definitions somewhere instead of redefining them in every
>> project. (Note that existing types like SupportsInt etc. were not what
>> we wanted.) This perhaps suggests that the ultimate number of type
>> aliases might be larger than we initially thought.
>>
>> On Sun, Apr 26, 2020 at 6:25 AM Ilhan Polat <[hidden email]> wrote:
>> >
>> > I agree that parking all these in a secondary namespace sounds a better option, can't say that I feel for the word "typing" though. There are already too many type, dtype, ctypeslib etc. Maybe we can go for a bit more distant name like "numpy.annotations" or whatever.
>> >
>> > On Sat, Apr 25, 2020 at 8:51 AM Kevin Sheppard <[hidden email]> wrote:
>> >>
>> >> 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 <[hidden email]> wrote:
>> >>>
>> >>>
>> >>>
>> >>> On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg <[hidden email]> 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
>> >>>> > [hidden email]
>> >>>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> NumPy-Discussion mailing list
>> >>>> [hidden email]
>> >>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>> >>>
>> >>> _______________________________________________
>> >>> NumPy-Discussion mailing list
>> >>> [hidden email]
>> >>> https://mail.python.org/mailman/listinfo/numpy-discussion
>> >>
>> >> _______________________________________________
>> >> NumPy-Discussion mailing list
>> >> [hidden email]
>> >> https://mail.python.org/mailman/listinfo/numpy-discussion
>> >
>> > _______________________________________________
>> > NumPy-Discussion mailing list
>> > [hidden email]
>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>> _______________________________________________
>> NumPy-Discussion mailing list
>> [hidden email]
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion