GeezerVison

@vadmium Thanks for your comments. I hope others chime in. Being fairly new to Python, I've found my chart (or your changes) very helpful in using the right str functions. To your point, it didn't really do much to shorten the page though.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

I have made the requested changes; please review again

Thanks for making the requested changes!

@ezio-melotti: please review the changes made to this pull request.

@ezio-melotti Do you review this PR?

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

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

This is how the (first half of the) table looks like. The table intentionally splits some cells and uses a | on others to show two alternative styles.

One issue with the table is that it takes over a page and it has a lot of whitespace. Maybe we could do something that looks like this instead (using a proper colspan):

We lose the direct mapping from str to the equivalent bytes method, but since they are still grouped it's easy enough to find it.

Hmm, well take my opinion as just one data point, but while I do definitely see the concern of it being rather long, at least from what I can see so far, I find the current format a good deal easier to skim and consult as a structured summary, at least personally to my eyes. If we're going to go with a structure similar to what you propose, I'm not sure if we even need a table at all, as opposed to just a bulleted list, which has essentially the same structure, is even more compact and is simpler to read and write, e.g.

• Searching and Replacing
  • str.find/str.rfind, str.index/str.rindex, str.startswith/str.endswith, str.count, str.replace
  • bytes.find/bytes.rfind, bytes.index/bytes.rindex, bytes.startswith/bytes.endswith, bytes.count, bytes.replace
• Splitting and Joining
  • str.split/str.rsplit, str.splitlines, str.partition/str.rpartition, str.join
  • bytes.split/bytes.rsplit, bytes.splitlines, bytes.partition/bytes.rpartition, bytes.join

Meanwhile, the original table could be made more compact and maintainable, at least in the source, by formatting it as a list-table rather than a full literal table.

Also, of the two styles, FWIW a real cell split rather than a raw | looks a lot cleaner and clearer to me.

See also these issues:

• Automatically tabulate module contents in the docs #83545
• Create a ToC entry for every function, method, class, etc sphinx-doc/sphinx#6316

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

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

@ezio-melotti I'm going through and rebooting and/or closing old Docs PRs. This one looks good and is an improvement over not having it. Would you be cool with merging? There would always be the option to iterate on it in the future. Thanks!

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

I agree that it's an improvement and can be iterated on.
If there are no objections, I'll merge early next year.