DEP: Speed up WarnOnWrite deprecation in buffer interface #13993
Conversation
numpy/core/src/multiarray/buffer.c
Outdated
| view->readonly = !PyArray_ISWRITEABLE(self); | ||
| /* | ||
| * If a read-only buffer is requested on a read-write array, we return a | ||
| * read-write buffer as per buffer protocol. |
There was a problem hiding this comment.
So to be clear, the behavior was not actually dubious as previously remarked, but is specified by the buffer protocol?
There was a problem hiding this comment.
I think the dubious part is either: The buffer protocol should be doing it differently, or, the deprecation side of things is dubious (since this deprecation was used before for the diagonal stuff).
There was a problem hiding this comment.
Note the incorrect indent. Tabs?
There was a problem hiding this comment.
oops, wow emberassing, I wonder which of my editors has such an insane setup :).
There was a problem hiding this comment.
Here's the text I was looking for:
Controls the readonly field. If set, the exporter MUST provide a writable buffer or else report failure. Otherwise, the exporter MAY provide either a read-only or writable buffer, but the choice MUST be consistent for all consumers.
Is "the choice MUST be consistent for all consumers." relevant here? I'm struggling to attach meaning to it.
3bbcadc to
08befe1
Compare
When a buffer interface does not request a writeable buffer, simply pass a read-only one when the warn on write flag is set. This is to give an easier way forward with avoiding the deprecation warnings: Simply do not ask for a writeable buffer. It will break code that expects writeable buffers but does not ask for them specifically a bit harder than would be nice. But since such code probably should ask for it specifically, this is likely fine (an RC release has to find out). The main reason for this is, that this way it plays very will with cython, which requests writeable buffers explicitly and if declared `const` is happy about read-only (so that using `const` is the best way to avoid the warning and makes code cleaner). Closes numpygh-13929, numpygh-13974
|
@seberg This is merged, so time for the forward port. The release notes should not be part of that. |
|
Issues this refers to to be closed are not auto closed on merge. Is that expected? |
It was a usage error. Each issue needs to have its own "Closes", they can't be listed with commas. |
|
But neither got closed, usually the first one closes. Anyway, the point is that I still see the issue on astropy CI while this was said to fix gh-13929. |
It was merged in the 1.17.x branch and hasn't been forward ported yet. Can you be more specific as to what is failing, I thought you had fixes? |
|
Oh, my mistake, I'm sorry, I didn't see that this is against the 1.17.x branch rather than master. I'll double check and report back either way. |
|
@bsipocz Great, I'm just now making the 1.17.0rc2 release. |
|
Will forward port it by tomorrow evening for sure. |
When a buffer interface does not request a writeable buffer,
simply pass a read-only one when the warn on write flag is set.
This is to give an easier way forward with avoiding the deprecation
warnings: Simply do not ask for a writeable buffer.
It will break code that expects writeable buffers but does not
ask for them specifically a bit harder than would be nice.
But since such code probably should ask for it specifically, this
is likely fine (an RC release has to find out).
The main reason for this is, that this way it plays very will with
cython, which requests writeable buffers explicitly and if declared
constis happy about read-only (so that usingconstis the bestway to avoid the warning and makes code cleaner).
Closes gh-13929, gh-13974