GeezerVison

I'll only keep the docs changes

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.

• pillow (11.1.0)

Which deprecated variables is Pillow using? I don't recall any deprecation warnings.

How will people know these are deprecated, if it's not documented?

The symbols are marked with __attribute__((deprecated)), so the compiler would have warned them (I guess?) Do you mean that we should keep the documentation entries? I thought we removed them in general

The symbols are marked with __attribute__((deprecated)), so the compiler would have warned them (I guess?)

Hmm, nothing at https://github.com/python-pillow/Pillow/actions/runs/14906674072/job/41870605210?pr=8948

Do you mean that we should keep the documentation entries?

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.

If we only remove the docs, we might end up keeping the deprecations in 3.15, making their status unclear.

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.

Which deprecated variables is Pillow using? I don't recall any deprecation warnings.

Pillow uses Py_FileSystemDefaultEncoding: source.

    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?

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 pip install -e . on Python 3.14.0b1 doesn't show any warnings, but it does with --verbose:

  src/_imagingft.c:145:13: warning: 'Py_FileSystemDefaultEncoding' is deprecated [-Wdeprecated-declarations]
    145 |             Py_FileSystemDefaultEncoding,
        |             ^
  /Library/Frameworks/Python.framework/Versions/3.14/include/python3.14/fileobject.h:22:1: note: 'Py_FileSystemDefaultEncoding' has been explicitly marked deprecated here
     22 | Py_DEPRECATED(3.12) PyAPI_DATA(const char *) Py_FileSystemDefaultEncoding;
        | ^
  /Library/Frameworks/Python.framework/Versions/3.14/include/python3.14/pyport.h:280:54: note: expanded from macro 'Py_DEPRECATED'
    280 | #define Py_DEPRECATED(VERSION_UNUSED) __attribute__((__deprecated__))
        |                                                      ^

Neither uv pip install -e . nor with --verbose showed the deprecation.

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.

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?

@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 deprecated-removed directive and only the deprecation version is rendered. Those are Py_UTF8Mode and Py_InteractiveFlag.

Should we push the removal version to 3.16 or just delay the removal of all variables?

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 deprecated-removed directive and only the deprecation version is rendered. Those are Py_UTF8Mode and Py_InteractiveFlag.

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.

I think it'd be a good idea yes. Should we raise it for both?

Yes, raised in the PyPA/pip Discord and they asked to comment here: pypa/pyproject-hooks#157 (comment)

or is uv bundling part of pip and it suffices to just change pip?

uv is all Rust, no Python.

This PR is stale because it has been open for 30 days with no activity.

See issue gh-149163 "Add PEP 741 PyInitConfig API to the limited C API". It's not directly related, but it may help projects to move to the PyInitConfig API.

This PR is stale because it has been open for 90 days with no activity.

This PR is superseded by #136277, a newer open pull request for the same issue (gh-133644), and it no longer merges cleanly. Closing to cull the number of open pull requests. Do not reopen this pull request without getting a go-ahead from a triager or core developer.