On Fri, Nov 25, 2022 at 9:36 AM Sebastian Berg
<sebast...@sipsolutions.net> wrote:
>
> Hi all,
>
> I would like to formally propose accepting NEP 51.  Without any concern
> voiced, we will consider it accepted within 7 days.
>
> As a reminder, this is to change the representation of NumPy scalars to
> be consistent and include the type name.
> That means the following representations:
>
>     np.float64(6.4)     ->  np.float64(6.4)
>     np.float64(np.nan)  ->  np.float64(nan)
>
> rather than just `6.4` or `nan`.  All scalars would follow this exact
> pattern of `np.<type_name>(value)`.
>
> There are some further details, for these please check the full NEP:
>
>     https://numpy.org/neps/nep-0051-scalar-representation.html
>
>
> For those interested in more details, a few notes:
>
> * To implement the NEP, we need to update NumPy docs.  I plan to
>   automate this (mostly) and such automation should also help others.
>   (I will make a brief note of this in the NEP.)
>   Help with this automation would be greatly appreciated, since this is
>   its own project.
>
> * I am not sure that the underscored versions `np.str_` and `np.bool_`
>   will be the correct names for long.  If we adjust them, then this
>   would propagate to the NEP.
>
> * There are a few implementation details in the NEP, I don't mind
>   adjusting them.  But do wish to be pragmatic about progressing if
>   there is no clearly formulated alternative.
>
> * Clearly we can always adjust the printing conventions, e.g. whether
>   to include the `np.` or whether NaN's should be `np.float64(nan)` or
>   not.  But bike-sheds happening now have a much better chance of
>   being heard :).

I always prefer things that have copy-pastability, so I would suggest
something like np.float64('nan'). It looks like the NEP already does
this for longdouble.

I'm assuming for float-64 and lower one can guarantee round-tripping
with the Python float literal.

The "np." also helps for copy-pastability for standard usage so that
sounds fine too. It would be useful to allow it to be disabled or
customized. For example, some libraries reuse NumPy dtype objects so
they may want to replace "np." with their own library name, or just
omit it. It wasn't clear to me if something like this is already part
of the NEP or not.

>
> 1. The current NEP states that we use `np.str_` and `np.bytes_`.  There
> is some chance that the top-level names could be changed, in that case
> the representation would change accordingly.  (I consider this an
> adjustment we can do without the NEP.)
>
> 2. To properly implement the NEP, we need to automate some of the
> documentation changes necessary.  This should also enable downstream to
> do the same or at least have a blueprint as a starting point.
> (Help with this work is greatly appreciated, since it is its own small
> project to hook into the doctest utilities.)

A reusable script would be nice, since many projects are going to have
doctests broken by this. I think there also may already be some
existing tooling that just "fixes" doctests by making them match their
output.

Aaron Meurer

>
> I plan on adding a brief note on about helping with doc updates to NEP
> when accepting it.  Ross was planning to add a table of changed
> examples, although I don't think that is necessary for accepting.
>
> Cheers,
>
> Sebastian
>
>
>
> On Fri, 2022-10-28 at 10:54 +0200, Sebastian Berg 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: 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: arch...@mail-archive.com

Reply via email to