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.shepp...@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 <sho...@gmail.com> wrote: > >> >> >> On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg < >> sebast...@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 >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
