On Mon, 2022-10-31 at 13:49 -0600, Aaron Meurer wrote:
> I like this. NumPy scalar printing is confusing to new users, who
> might think they are Python scalars. And even if you understand them,
> it's always been annoying that you have to do further introspection
> to
> see the dtype. I also like the longdouble change (the name float128
> has misled me in the past), and the decision to make everything
> copy-paste round-trippable.
>
> Are there also plans to add "np." to array() and the string forms of
> other objects?
Didn't include changing arrays here, since I thought I would focus on
scalars only.
Clearly it is a plausible change though, and we could add it in this
NEP. Although, I suspect it is just as well to do it separately.
Including the `np.` for scalars seemed more clear, but since it is
pretty common to exclude modules in repr, I would also be happy to not
do it.
It would make a bit of a presumption that NumPy is the obvious provider
of `int32` (and if others do, they are likely compatible).
- Sebastian
>
> Aaron Meurer
>
> On Fri, Oct 28, 2022 at 2:55 AM Sebastian Berg
> <sebast...@sipsolutions.net> wrote:
> >
> > Hi all,
> >
> > As mentioned earlier, I would like to propose changing the
> > representation of scalars in NumPy. Discussion and ideas on
> > changes
> > are much appreciated!
> >
> > The main change is to show scalars as:
> >
> > * `np.float64(3.0)` instead of just `3.0`
> > * `np.True_` instead of `True`
> > * `np.void((3, 5), dtype=[('a', '<i8'), ('b', 'u1')])` instead of
> > `(3, 5)`
> > * Use `np.` rather than `numpy.` for datetime/timedelta.
> >
> > This way it is clear for users that they are dealing with NumPy
> > scalars
> > which behave different from Python scalars.
> > The `str()` that is given when using `print()` and the way arrays
> > are
> > shown will be unchanged.
> >
> > The NEP draft can be found here:
> >
> > https://numpy.org/neps/nep-0051-scalar-representation.html
> >
> > and it includes more details and related changes.
> >
> > The implementation is largely finished and can be found here:
> >
> > https://github.com/numpy/numpy/pull/22449
> >
> > W are fairly late in the release cycle and the change should not
> > block
> > other things. So, the aim is to merge it early in the next release
> > cycle. That way downstream has time to fix documentation is
> > wanted.
> >
> > Depending on how discussion goes, I hope to formally propose the
> > NEP
> > fairly soon, so that the merging the implementation doesn't need to
> > wait on NEP approval.
> >
> > Cheers,
> >
> > Sebastian
> >
> >
> >
> >
> > On Thu, 2022-09-08 at 11:38 +0200, Sebastian Berg wrote:
> > >
> > > TL;DR: NumPy scalars representation is e.g. `34.3` instead of
> > > `float32(34.3)`. So the representation is missing the type
> > > information. What are your thoughts on changing that?
> > >
> > >
> > > Hi all,
> > >
> > > I am thinking about the next steps for NEP 50 (The NEP wants to
> > > fix
> > > the
> > > NumPy promotion rules, especially with respect to scalars):
> > >
> > > https://numpy.org/neps/nep-0050-scalar-promotion.html
> > >
> > > In relation to that, there was one point that Stéfan brought up
> > > previously.
> > >
> > > The NumPy scalars (representation) currently print as numbers:
> > >
> > > >>> np.float32(34.3)
> > > 34.3
> > > >>> np.uint8(5)
> > > 5
> > >
> > > That can already be confusing now. However, it gets more
> > > problematic
> > > if NEP 50 is introduced since the behavior between a Python
> > > `34.3`
> > > and
> > > `np.float32(34.3)` would differ more than it does now (please
> > > refer
> > > to
> > > the NEP).
> > >
> > > The change would be that we should print as:
> > >
> > > float64(34.3) (or similar?)
> > >
> > > This Email is mainly to ask for any feedback or concern on such a
> > > change. I suspect we may have to write a very brief NEP about
> > > it.
> > >
> > > If there is little concern, maybe we could move forward such a
> > > change
> > > promptly. Otherwise it could be moved forward together with NEP
> > > 50
> > > and
> > > take effect in a "major" release [1].
> > >
> > > Cheers,
> > >
> > > Sebastian
> > >
> > >
> > >
> > > [1] Note that for me, even a major release would hopefully not
> > > affect
> > > the majority of users or be very disruptive.
> > >
> > > _______________________________________________
> > > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > > To unsubscribe send an email to numpy-discussion-le...@python.org
> > > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > > Member address: sebast...@sipsolutions.net
> >
> >
> > _______________________________________________
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: asmeu...@gmail.com
> _______________________________________________
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: sebast...@sipsolutions.net
_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com
