On Mon, Oct 9, 2023 at 2:29 PM Nathan <nathan.goldb...@gmail.com> wrote:
> However, one thing we can do now is, for that one particular symbol that > we know is going to be in every pickle file and probably never elsewhere, > is intercept that one import and instead of generating a generic warning > about np.core being deprecated, we instead make that specific version of > the deprecation warning mentions NumpyUnpickler. I'll make sure this gets > done. > > We *could* just allow that import to happen without a warning, but then > we're stuck keeping np.core around even longer and we also will still > generate a deprecation warning for an import from np.core if the pickle > file happens to include any other numpy types that might generate imports > in np.core. > My preferred option would be to keep restoring old NumPy pickles working indefinitely, and also to preserve backwards compatibility for pickles written in newer versions of NumPy. We can still do the rest of the numpy.core cleanup, but it's OK if we keep a bit of compatibility code in NumPy indefinitely. I don't think warnings would help much in this case, because if somebody is currently distributing pickled numpy arrays despite all of our warnings not to do so, they are unlikely to go back and update their old files. We could keep around numpy.core.multiarray as a minimal stub for only this purpose, or potentially only define the object numpy.core.multiarray._reconstruct.
_______________________________________________ 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
