Replace the "Status of the Python branches" table with a csv.

[ezio-melotti]

This PR fixes#883.

I kept the Sphinx markup in the csv, or otherwise it would have been lost. The markup should be easy enough to remove while parsing, and it only affects PEPs and dates. I checked if there was a way to include a separate column without markup and then ignore it in the table, but there's no such option.

While I was at it, I also fixed the column widths. Here's a comparison of the result (csv table on top, old one below):

[Mariatta]

The csv table looks much cleaner this way.

[encukou]

Could you convert the EOL table as well? https://devguide.python.org/devcycle/#end-of-life-branches

[ezio-melotti]

If we start adding more csv files, I wonder if it would make sense to add them in a new include dir. The reasons for doing this are:

• if people start using the files now, and then we move them, we will break their scripts;
• the root dir is already crowded with rst (and other files);
• I'm planning to add more files in Machine-parsable developers list #848.

[ezio-melotti]

Relevant discussion about the two tables (cc @hugovk, @encukou): endoflife-date/endoflife.date#711

[ezio-melotti]

I updated the PR to include the end-of-life table, and moved both the csvs in a new include directory.
I'll wait after #901 is done to merge this, as to not create additional conflicts in that PR.

[AA-Turner]

Does auto work for widths?

Another option would be to combine the CSVs, and use a very simple extension in conf.py to split them by EOL/active and add the italics -- that would allow for easier parsing for external consumers such as endoflife.date.

A

[ezio-melotti]

Does auto work for widths?

I can give that a try. I set those widths manually in order to keep each row in a single line (see e.g. the screenshots in the first message).

Another option would be to combine the CSVs,

I'm trying to gather some feedback from the endoflife folks and pydotorg in order to figure out their needs. If it turns out that a single table is better, I can combine them.

and use a very simple extension in conf.py to split them by EOL/active and add the italics -- that would allow for easier parsing for external consumers such as endoflife.date.

What extension? I also don't like too much the rst markup in the csv, especially the :pep:`...`s applied to all the PEPs in the PEP column, but the italic is not applied to all rows and it's easy enough to remove afterwards that it's probably better to keep it there.

[ezio-melotti]

Hmm, locally the tables look fine after removing the :widths:, but on https://cpython-devguide--884.org.readthedocs.build/#status-of-python-branches they don't. Here I tested with both Sphinx 5.0.1 and 5.0.2 -- perhaps readthedocs is using an older version?

[CAM-Gerlach]

For reference, this is how they look in FF on Windows on the preview.

Screenshot

I checked if there was a way to include a separate column without markup and then ignore it in the table, but there's no such option.

You could use Sphinx CSV Filter, both to include/exclude specific columns (e.g. with/without markup), and also to only include specific rows (e.g. that are marked EOL or not). That would avoid having to write a custom directive.

[ezio-melotti]

I updated the PR after the Devguide reorganization, reintroduced the :widths: to fix the rendering issues and also to make both tables consistent, and fixed a few other minor things.

I'm not sure if it's worth unifying the two CSVs and/or tables, since that adds an extra dependency and complexity.

[CAM-Gerlach]

I'm not sure if it's worth unifying the two CSVs and/or tables, since that adds an extra dependency and complexity.

You could just put them in the same table, since there's already a Status column, if there were an easy way to clearly separate supported from unsupported statuses (e.g. by row color). But I'm not sure if there is.

[hugovk]

I'll wait after #901 is done to merge this, as to not create additional conflicts in that PR.

#901 is now merged.

[hugovk]

It would be useful to have machine-readable data, for example to automate https://python-release-cycle.glitch.me/

JSON would be preferred but CSV should be fine too.

(https://endoflife.date/api/python.json doesn't do prereleases.)

[CAM-Gerlach]

A couple updates to the release dates

[ezio-melotti]

As discussed in the docs meeting, I now merged this. There are more changes we are considering, e.g. merging the two table or creating a JSON file that is then used to create these CSVs, but those will be handled in separate PRs.

[encukou]

FWIW, I think the source should be a human-writable format, and we should generate a JSON for the machines to consume (like https://peps.python.org/api/peps.json). And we should tell people to expect the source format to change whenever we feel like it.
(That'll need a Sphinx plugin, but if we want to move the formatting out of the tables, one will be needed anyway.)

[hugovk]

Thanks! Let's continue on python/docs-community#67.