-
-
Notifications
You must be signed in to change notification settings - Fork 11.4k
TYP: stub lib._datasource
and fix lib._npyio_impl
#28303
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
that was the last one for today |
This seems like quite a bit of changes. Unless these are related to regressions, I am really not sure that we should backport it and risk other regressions (and also bug fixes/new features can create regressions). |
This comment was marked as outdated.
This comment was marked as outdated.
I partially reverted the changes to the |
Thanks Joren. |
Backports of the following PRs: numpy#28295, numpy#28296, numpy#28297, numpy#28298, numpy#28299, numpy#28300, numpy#28301, numpy#28302 numpy#28303 Squashed commits of the following: commit a9267179555caf49c109a13560c3af81b7fc2a7a Author: jorenham <[email protected]> Date: Sat Feb 8 16:51:24 2025 +0100 TYP: stub ``lib._datasource`` and fix ``lib._npyio_impl`` commit 443ae333a12abecfad6faa32a55008d2312c7d92 Author: jorenham <[email protected]> Date: Sat Feb 8 16:22:58 2025 +0100 TYP: fix and improve ``numpy._core.arrayprint`` commit 3bf77939042838edb417507ec2099951c7ad804b Author: jorenham <[email protected]> Date: Sat Feb 8 15:57:32 2025 +0100 TYP: stub ``lib.recfunctions`` commit 80319f25c499a2b87eb271a9e7a81bb0ce3e1f85 Author: jorenham <[email protected]> Date: Sat Feb 8 15:52:10 2025 +0100 TYP: stub ``lib.introspect`` commit 1d693e9601aaf9f5bb5a915385cc52a0162efcff Author: jorenham <[email protected]> Date: Sat Feb 8 15:49:53 2025 +0100 TYP: stub ``lib.user_array`` and ``lib._user_array_impl`` commit d56f22f263ddf02a01fc15bf576862c51f22addd Author: jorenham <[email protected]> Date: Sat Feb 8 15:45:36 2025 +0100 TYP: stub ``numpy.lib._iotools`` commit ca2024aa706a85a5011c2bb55aba29e5d5da40bd Author: jorenham <[email protected]> Date: Sat Feb 8 15:39:59 2025 +0100 TYP: stub ``numpy._configtool`` and ``numpy._distributor_init`` commit ec7fdc9ca259b4fedfbb88f606818271fed63ee0 Author: jorenham <[email protected]> Date: Sat Feb 8 15:36:46 2025 +0100 TYP: stub ``numpy._expired_attrs_2_0`` commit f2f078c4f81065dcf0855d95067d7c32686e972f Author: jorenham <[email protected]> Date: Sat Feb 8 15:30:32 2025 +0100 TYP: stub ``numpy._globals``
That is good then, but stay aware that any non-trivial change can introduce a new bug or behavior change by accident. So if a change isn't simple and the bug it it fixes is not bad, then just waiting for the new release is better IMO. EDIT: Basically: if any user starts pinning bug-releases due to it breaking their CI often, then IMO, we backported too agressively. |
Do you think that new stubs for previously unstubbed modules (which I personally consider a bug, but I'm probably biased) should be backported, @seberg ? |
The size just made me paus. I guess I don't care about new stubs as such if/since they cannot cause regressions for anyone? Seems also a bit unnecessary. Although, maybe they are different from new features. |
backport of numpy/numtype#85
changes in
lib._npyio
:max_header_size
kwarg toload
NpzFile
dunder method paramsannotate the possibility for theNpzFile.{zip,f}
attrs to becomeNone
TypeAlias