[Numpy-discussion] 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 <kevin.k.sheppard at gmail.com>
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 <shoyer at gmail.com> wrote:
>
>>
>>
>> On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg <
>> sebastian at 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 at python.org
>>> > https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>>>
>>> _______________________________________________
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion at python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>>
>> _______________________________________________
>> NumPy-Discussion mailing list
>> NumPy-Discussion at python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20200426/ffc38b02/attachment.html>