@ZeroIntensity Thanks for review! Fixed (I hope :)

I think that if this is internal-only, it would be better to completely drop it from public headers rather than document it as such.

(Don't do this yet, by the way. Let's come to a consensus in the issue.)

As no comments from @iritkatriel or @markshannon I propose to make it internal as @ZeroIntensity suggested and rename it to _Py_TPFLAGS_PREHEADER.

@encukou WDYT?

Per PEP-387, removing (or renaming) it probablyneeds a deprecation cycle. Or is there evidence that no existing code uses it?

Since the tp_flags flags must be public, it seemed sensible to put Py_TPFLAGS_PREHEADER in the same header.
I have no objection to moving it.

It might be better to rename it to Py_TPFLAGS_VM_MANAGED_FIELDS to focus on the semantics, not the layout, and keep it public?

Per PEP-387, removing (or renaming) it probablyneeds a deprecation cycle. Or is there evidence that no existing code uses it?

https://grep.app/search?q=Py_TPFLAGS_PREHEADER shows close to nothing of usage. Also, I'm downloading top-pypi packages to checks usage (as described here https://hugovk.dev/blog/2022/how-to-search-5000-python-projects/), will report as it finished.

It might be better to rename it to Py_TPFLAGS_VM_MANAGED_FIELDS to focus on the semantics, not the layout, and keep it public?

@markshannon WDYT about wordings in this PR? Can you suggest some improvements?

will report as it finished.

Searched over 13k+ packages:

➜ .\python.exe ../misc/cpython/search_pypi_top.py -q ..\top-pypi\output\  "Py_TPFLAGS_PREHEADER"
..\top-pypi\output\recordclass-0.23.1.tar.gz: recordclass-0.23.1/lib/recordclass/_dataobject.c: tp->tp_flags &= ~Py_TPFLAGS_PREHEADER;

Time: 0:01:10.586519
Found 1 matching lines in 1 projects

➜ ( Get-ChildItem ..\top-pypi\output\ | Measure-Object ).Count;
13961

It might be better to rename it to Py_TPFLAGS_VM_MANAGED_FIELDS to focus on the semantics, not the layout, and keep it public?

If it's public, it's best not to rename it.

If it's public, it's best not to rename it.

I think it's probably safe to rename it, at least for 3.14. Based on a code search, we're the only ones who use it (all the non-CPython mentions are people copying our headers).

If it's public, it's best not to rename it.

I think it's probably safe to rename it, at least for 3.14. Based on a code search, we're the only ones who use it (all the non-CPython mentions are people copying our headers).

Only recordclass uses it - #135861 (comment)

@ZeroIntensity Please take a look.

It's hard to deprecate a macro, so adding warnings in docs look best.
Thank you for sticking to this, @sergey-miryanov!

Thanks everyone!