> 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 <josh.craig.wil...@gmail.com> 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 <ilhanpo...@gmail.com> 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 < > 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 > _______________________________________________ > 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
