gh-133644: remove deprecated global configuration variables #133654
Conversation
The following are also removed: - `_Py_SetFileSystemEncoding` - `_Py_ClearFileSystemEncoding` - `_Py_HasFileSystemDefaultEncodeErrors`
|
I may have held the GIL for too long on Windows builds or something like that. Will investigate. |
Yeah, I actually wondered whether they were stable or not but apparently they are :') I only thought about this when I wrote the other PRs... However, this makes my life much easier then! |
|
UPDATE: I added matching lines and I ignored Pillow which is up to date. A code search on PyPI top 8,000 projects finds matchs in 20 projects:
It would feel safer to merge such change once the number of affected projects would be 10 or less. Porting code to Cython has such complex code just to replace the deprecated #if CYTHON_COMPILING_IN_LIMITED_API || (CYTHON_COMPILING_IN_CPYTHON && PY_VERSION_HEX >= 0x030C0000)
// Py_OptimizeFlag is deprecated in Py3.12+ and not available in the Limited API.
static int __pyx_assertions_enabled_flag;
#define __pyx_assertions_enabled() (__pyx_assertions_enabled_flag)
static int __Pyx_init_assertions_enabled(void) {
PyObject *builtins, *debug, *debug_str;
int flag;
builtins = PyEval_GetBuiltins();
if (!builtins) goto bad;
// Not using PYIDENT() here because we probably don't need the string more than this once.
debug_str = PyUnicode_FromStringAndSize("__debug__", 9);
if (!debug_str) goto bad;
debug = PyObject_GetItem(builtins, debug_str);
Py_DECREF(debug_str);
if (!debug) goto bad;
flag = PyObject_IsTrue(debug);
Py_DECREF(debug);
if (flag == -1) goto bad;
__pyx_assertions_enabled_flag = flag;
return 0;
bad:
__pyx_assertions_enabled_flag = 1;
// We (rarely) may not have an exception set, but the calling code will call PyErr_Occurred() either way.
return -1;
}
#else
#define __Pyx_init_assertions_enabled() (0)
#define __pyx_assertions_enabled() (!Py_OptimizeFlag)
#endif |
Let's do it that way. For now, I'll only keep the docs changes and revert the runtime changes (I'll anyway need to do that eventually). |
How will people know these are deprecated, if it's not documented? We have 12 months until 3.15's feature freeze (and and 17 until 3.15's release), things may have changed in that time. We can also open issues/PRs with the above projects.
Which deprecated variables is Pillow using? I don't recall any deprecation warnings. |
The symbols are marked with |
Hmm, nothing at https://github.com/python-pillow/Pillow/actions/runs/14906674072/job/41870605210?pr=8948
Yes. This PR isn't removing any deprecations, it's only removing documentation about them. If we only remove the docs, we might end up keeping the deprecations in 3.15, making their status unclear. Let's remove the deprecations and their docs at the same time. |
Ah, I see what you mean. Ok let's remove them in one go. Or if someone else has a cleaner PR for the runtime changes, they can just merge this one into theirs and they don't need to update the docs themselves. |
Pillow uses if (!PyArg_ParseTupleAndKeywords(
args,
kw,
"etf|nsy#n",
kwlist,
Py_FileSystemDefaultEncoding, # <==== HERE ====
&filename,
&size,
&index,
&encoding,
&font_bytes,
&font_bytes_size,
&layout_engine
)) {
return NULL;
}Oh, but this code path is only taken on Python 3.10 and older! So you can ignore Pillow which is up to date! |
|
Hooray! Although I don't see any deprecations in the 3.9 build logs, should there be? |
No, the deprecation was added later. |
|
OK, thanks. Unrelated to this issue, I wanted to see what the deprecation looks like. Just for testing, I edited the Pillow code so it only has a code path hitting the deprecation. A normal Neither It's unfortunate that neither show the warning in normal use, as their maintainers will be less likely to see them. Perhaps something to raise with pip and uv. |
I think it'd be a good idea yes. Should we raise it for both? or is uv bundling part of pip and it suffices to just change pip? |
…ted-globals-133644
|
@vstinner @hugovk Actually, there were two variables that were slated for removal and notified in 3.12 What's New I think but they never had a Should we push the removal version to 3.16 or just delay the removal of all variables? |
Both variables emit deprecation warnings using Py_DEPRECATED(): Py_DEPRECATED(3.12) PyAPI_DATA(int) Py_UTF8Mode;
Py_DEPRECATED(3.12) PyAPI_DATA(int) Py_InteractiveFlag;I don't think that the doc is a big deal here, Py_DEPRECATED() is more important. |
|
Also, all global configuration variables are documented in "Pending removal in Python 3.15": https://docs.python.org/dev/whatsnew/3.14.html#id13 |
|
Ok, I'll update the docs first for 3.13 and 3.14. I always hate doing backports, so would it be fine for me to first update main and let the bot make the backports automatically? that way, even 3.15 is consistent. One way why I can think of why it's annoying to users is that they don't necessarily land on the What's New page if they make a Google search. |
Yes, raised in the PyPA/pip Discord and they asked to comment here: pypa/pyproject-hooks#157 (comment)
uv is all Rust, no Python. |
Ok, this one is really tricky and I really need more eyes to be sure about it, namely @vstinner's eyes.
There are two global configuration variables that were marked as deprecated but not explicitly slated for removal in the docs, namely
Py_UTF8ModeandPy_InteractiveFlag. As such, I've left them untouched. They were however mentioned in the "pending removals" documents so I don't know if we can just remove them (note that users are more likely to land on the C API page rather than the what's new page when they are looking for docs).I'll write a NEWS entry afterwards.
📚 Documentation preview 📚: https://cpython-previews--133654.org.readthedocs.build/