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

If we start adding more csv files, I wonder if it would make sense to add them in a newinclude 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 inMachine-parsable developers list #848.

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

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

Doesauto work for widths?

Another option would be to combine the CSVs, and use a very simple extension inconf.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

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.

Hmm, locally the tables look fine after removing the:widths:, but onhttps://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?

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

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 useSphinx 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.

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.

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 aStatus 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.

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

#901 is now merged.

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.

FWIW, I think the source should be a human-writable format, and we shouldgenerate a JSON for the machines to consume (likehttps://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.)

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