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