[Numpy-discussion] Re: mypy occasional error on _UnknownType in _array_like.py since 1.22 or 1.23
On Mon, Oct 10, 2022 at 11:02 PM Nick Gerner wrote: > On Mon, Oct 10, 2022 at 1:35 PM Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Mon, Oct 10, 2022 at 12:27 PM Nick Gerner >> wrote: >> >>> I upgraded from 1.21 to 1.23.3 recently and got a variety of mypy >>> issues. I seem to have resolved all of them, but I occasionally still see >>> this show up: >>> >>> .venv/lib/python3.10/site-packages/numpy/_typing/_array_like.py:153: >>> error: Type argument "_UnknownType" of "dtype" must be a subtype of >>> "generic" [type-var] >>> >>> On mypy 0.981 this is not 100% repro and if I restart dmypy it goes >>> away... until it comes back. I just now upgraded to mypy 0.982 and didn't >>> get it on one run, at least not right away. Maybe this was some kind of >>> mypy issue, but time will tell. >>> >>> I haven't seen exactly this error getting posted anywhere. I know this >>> is a fairly recent change and it looks like there's a lot of type hinting >>> work going on (excellent work! I love it, thank you numpy devs!). >>> >>> Anyone else got any insight on what's going on here? Is this a known >>> issue? Is this a mypy issue? >>> >>> Thanks everyone. >>> >> >> I'd be very curious to know if 0.982 fixes things. I know that using >> python 3.10.7 causes problems for mypy < 0.981. >> >> Chuck >> > > Sadly, it does not seem to resolve the problem. I've run into the issue > with mypy 0.982 several times today. I am running python 3.10.7. > > I've posted to the mypy gitter as well in case it's an issue on their end. > I guess I should add that I haven't seen it running mypy, only running > dmypy. That and the fact that it's not 100% repro does make it seem like a > mypy issue. > That's a safe guess I think. Mypy is very flaky, and it hasn't gotten better over time. Its caching is broken so runs aren't reproducible, as you are seeing here. Every new release breaks things, and even the same release behaves differently between Python versions (including bugfix versions). For projects with complex type annotations like NumPy, you cannot count on Mypy working fully beyond the exact config that is tested in CI. For individual projects, the solution is to pin down that one config that has to pass, and always use that in CI and local development. But that doesn't help end users, because they're mixing different libraries into one environment. I'm not sure if there's a better solution than filing Mypy bugs and using `# type: ignore` liberally. Ralf ___ 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
[Numpy-discussion] Re: NEP 50 and integers (e.g. uint8 together -1)
Hi all, just to mention it, there is a PR ready on this: https://github.com/numpy/numpy/pull/22385 it necessecitates some changes to the NumPy test suite and will do similar at least for SciPy downstream I currently suspect we will give it a shot soon, but am not opposed at all with discussing especially allowing: np.uint8(-1) i.e. using the negative range of the corresponding signed integer explicitly for the `np.uint8`, `np.uint16`. But still disallow it for other operations like `np.array([-1], dtype=np.uint8)`. As I said, my main interest is pushing NEP 50 related change: https://github.com/numpy/numpy/pull/21875 which this will simplify. If this PR seems tricky to move forward, that is fine, but I would like to push that PR without the simplification. (Decoupling this change from NEP 50 at some complexity cost.) Cheers, Sebastian On Tue, 2022-10-04 at 17:24 +0200, Ralf Gommers wrote: > On Thu, Sep 29, 2022 at 10:10 AM Sebastian Berg > > wrote: > > > On Wed, 2022-09-28 at 16:44 -0700, Stefan van der Walt wrote: > > > Hi Sebastian, > > > > > > On Wed, Sep 28, 2022, at 12:11, Sebastian Berg wrote: > > > > np.array([1, 2], dtype="uint8") + (-1) > > > > > > > > which currently returns an "int16" array must raise an error. > > > > This > > > > is > > > > because we want to return a uint8 array but the -1 cannot be > > > > represented well by -1. > > > > > > Did you mean: the -1 is not representable in uint8? > > > > Sorry yes. With NEP 50, we do not look at the value (initially) so > > determine that the operation must be handled as: > > > > uint8 + uint8 -> uint8 > > > > We then try to convert the -1 to uint8. That conversion would > > raise an > > error, because previously the result was an int16. > > (This is to prevent silent unexpected result changes and seemed > > like > > the more reasonable behavior.) > > > > On the other hand, assignments like: > > > > uint8_arr[0] = -1 > > np.array([-1], dtype=np.uint8) > > > > do happily convert the -1 to `uint8`, currently. If we keep > > allowing > > these, we have two slightly different conversions: one that fails > > and > > one that does not. > > > > This is fine, but maybe we actually want it to always fail in the > > future? > > > > It seems better to always raise an exception indeed. So if it > simplifies > your PR to do that now, I'd say go for it. > > Cheers, > Ralf > ___ > 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
