On Tue, 2022-11-29 at 14:51 -0700, Aaron Meurer wrote:
> 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.
> >
<snip>
> > * 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.
It is a bit different for longdouble because for longdouble you should
always put quotes anyway.
Note that if we do that, we somewhat also have to do it also for:
array([1.0, nan, 2.0])
which currently doesn't print quotes. But then we need to include the
dtype in the output, or that doesn't round-trip anymore (even with
defining `nan`).
>
> 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.
This changes printing of instances, classes always print as
`numpy.uint8` and I am not planning on changing that.
I added a way to format a scalars repr when the dtype is known (i.e.
the same way as it would be when calling `repr(array)`) in the NEP.
I didn't attach it to the scalar though, either way it feels a bit
unwieldy, but I don't have a good idea for providing it and `str()`
basically does this also.
>
> >
> > 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.
Yeah, such a tool should be good enough in practice, do you know where
to find it?
Otherwise hacking a doctest helper seems very possible.
- Sebastian
>
> 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: 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
