Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions Doc/c-api/buffer.rst
Original file line number Diff line number Diff line change
Expand Up @@ -261,6 +261,10 @@ readonly, format
MUST be consistent for all consumers. For example, :c:expr:`PyBUF_SIMPLE | PyBUF_WRITABLE`
can be used to request a simple writable buffer.

.. c:macro:: PyBUF_WRITEABLE

This is a :term:`soft deprecated` alias to :c:macro:`PyBUF_WRITABLE`.
Comment on lines +264 to +266
Copy link
Member

@StanFromIreland StanFromIreland Nov 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
.. c:macro:: PyBUF_WRITEABLE
This is a :term:`soft deprecated` alias to :c:macro:`PyBUF_WRITABLE`.
.. c:namespace:: NULL
.. c:macro:: PyBUF_WRITEABLE
This is a :term:`soft deprecated` alias to :c:macro:`PyBUF_WRITABLE`.

I see this was recently done for a different alias, i.e., it is put under what it is aliased to:

cpython/Doc/c-api/long.rst

Lines 196 to 205 in be1c72a

.. c:namespace:: NULL
.. c:function:: long PyLong_AS_LONG(PyObject *obj)
A :term:`soft deprecated` alias.
Exactly equivalent to the preferred ``PyLong_AsLong``. In particular,
it can fail with :exc:`OverflowError` or another exception.
.. deprecated:: 3.14
The function is soft deprecated.

IMO it also makes sense to add a .. deprecated:: 3.15.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really don't think we should be backporting deprecations. It implies that it's valid to use up until that version, which we don't want people to think.

In general, it's very uncommon to backport deprecations. This is the second time someone has pointed to that as precedent, but I would have disagreed there too.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed it from the suggestion, but why not keep it here and just edit Miss Islington's backports to remove it? I volunteer to do it if you want.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need C API WG approval in order to do a deprecation, and that can take months. I'd like to do deprecations after we've gotten everything documented so we're not blocked by them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, what does .. c:namespace:: NULL do? I don't see a difference in the output.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, what does .. c:namespace:: NULL do? I don't see a difference in the output.

It allows for cross referencing as the macro name IIUC, per the docs:

Using NULL ... as the scope will change to global scope.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh, I don't follow. This should be in the global namespace already. I think that only applies if you're using something like namespace-push, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I simply copied what Petr had done, I've not tested it yet.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Testing it, it is not in the global namespace, and I need to use :c:macro:`PyBUF_WRITABLE.PyBUF_WRITEABLE` to get a link.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... I just tested it too, using :c:macro:`PyBUF_WRITEABLE` works just fine on my end.


.. c:macro:: PyBUF_FORMAT

Controls the :c:member:`~Py_buffer.format` field. If set, this field MUST
Expand Down
Loading