If the CI noise in downstream libraries is particularly painful, we could
switch to `PendingDeprecationWarning` instead of `DeprecationWarning` to
make it easier to add the warnings to an ignore list.
I think this might make the warning less visible to end users though, who
are the users that this deprecation was really aimed at.
Eric
On Mon, 7 Dec 2020 at 11:39, Ralf Gommers <ralf.gomm...@gmail.com> wrote:
>
>
> On Sun, Dec 6, 2020 at 4:23 PM Sebastian Berg <sebast...@sipsolutions.net>
> wrote:
>
>> On Sat, 2020-12-05 at 20:12 -0700, Charles R Harris wrote:
>> > On Sat, Dec 5, 2020 at 4:31 PM Juan Nunez-Iglesias <j...@fastmail.com>
>> > wrote:
>> >
>> > > Hi all,
>> > >
>> > > At the prodding [1] of Sebastian, I’m starting a discussion on the
>> > > decision to deprecate np.{bool,float,int}. This deprecation broke
>> > > our
>> > > prerelease testing in scikit-image (which, hooray for rcs!), and
>> > > resulted
>> > > in a large amount of code churn to fix [2].
>> > >
>> > > To be honest, I do think *some* sort of deprecation is needed,
>> > > because for
>> > > the longest time I thought that np.float was what np.float_
>> > > actually is. I
>> > > think it would be worthwhile to move to *that*, though it’s an even
>> > > more
>> > > invasive deprecation than the currently proposed one. Writing `x =
>> > > np.zeros(5, dtype=int)` is somewhat magical, because someone with a
>> > > strict
>> > > typing mindset (there’s an increasing number!) might expect that
>> > > this is an
>> > > array of pointers to Python ints. This is why I’ve always preferred
>> > > to
>> > > write `dtype=np.int`, resulting in the current code churn.
>> > >
>> > > I don’t know what the best answer is, just sparking the discussion
>> > > Sebastian wants to see. ;) For skimage we’ve already merged a fix
>> > > (even if
>> > > it is one of dubious quality, as Stéfan points out [3] ;), so I
>> > > don’t have
>> > > too much stake in the outcome.
>> > >
>> > > Juan.
>> > >
>> > > [1]:
>> > >
>> https://github.com/scikit-image/scikit-image/pull/5103#issuecomment-739334463
>> > > [2]: https://github.com/scikit-image/scikit-image/pull/5103
>> > > [3]:
>> > >
>> https://github.com/scikit-image/scikit-image/pull/5103#issuecomment-739368765
>> > >
>> >
>> > I checked pandas and astropy and both have several uses of the
>> > deprecated
>> > types but should be easy to fix. I suppose the question is if we want
>> > to
>> > make them fix things *right now* :)
>> >
>>
>>
>> The reason why I thought it might be good to bring this up again is
>> that I am not sure clear on how painful the deprecation is; which
>> should be weighed against the benefit. And the benefit here is only
>> moderate.
>>
>
> It will be painful as in "lots of churn", but the fixes are
> straightforward. And it's clear many knowledgeable users didn't know they
> were aliases, so there is something to gain here.
>
> Whether or not we revert the deprecation, I'd be in favor of improving the
> docs to answer the most common questions and pitfalls, like:
>
> - What happens when I use Python builtin types with the dtype keyword?
> - How do I check if something is an integer array? Or a NumPy or Python
> integer?
> - What are default integer, float and complex precisions on all platforms?
> - How do I iterate over all floating point dtypes when writing tests?
> - Which of the many equivalent dtypes should I prefer? --> use float64,
> not float_ or double
> - warning: float128 and float96 do not exist on all platforms
> -
> https://github.com/scikit-learn/scikit-learn/wiki/C-integer-types%3A-the-missing-manual
>
> Related: it's still easy to have things leak into the namespace
> unintentionally - `np.sys` and `np.os` exist too. I think we can probably
> clean those up without a deprecation, but we should write some more public
> API tests that prevent this kind of thing.
>
> Cheers,
> Ralf
>
>
>
>> Thus, with the things now in and a few more people exposed to it, if
>> anyone thinks its a bad idea or that we should delay, I am all ears.
>>
>> Cheers,
>>
>> Sebastian
>>
>>
>> > Chuck
>> > _______________________________________________
>> > 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
