Skip to content

bpo-41787: add references to PEP424, and a sentence on purpose for __length_hint__ #22269

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cameron-simpson
Copy link

@cameron-simpson cameron-simpson commented Sep 16, 2020

@cameron-simpson
Copy link
Author

Please add the "skip news" label, I can't seem to.

@cameron-simpson
Copy link
Author

On consideration, inclined to change "Used by" to "Consulted by".

@merwok
Copy link
Member

merwok commented Sep 16, 2020

Would you mind posting a screenshot of the result?

@cameron-simpson
Copy link
Author

cameron-simpson commented Sep 17, 2020

Would you mind posting a screenshot of the result?

bpo-41787--pep424-refs--shot1

@merwok
Copy link
Member

merwok commented Sep 17, 2020

Ah! The output feels a bit wrong to me; I think the versionadded note (with optional details) should be separate from the PEP note.

@cameron-simpson
Copy link
Author

Ah! The output feels a bit wrong to me; I think the versionadded note (with optional details) should be separate from the PEP note.

I differ on this. They're together for two reasons: visual compactness (just one line of change/introduced/reference info) and because the introduction in the release is closely tied to the associated PEP.

OTOH, on visual review the capital "O" in "originally" should be lowercased, so that the "New in" line reads cleanly as "new here, because of this PEP".

I'm rather uncomfortable with pulling the "originally specified in" line out into a distinct paragraph - it will make the docs far more vertically spaced for a small addition, and as stated I consider the version and the PEP to be very closely associated.

Bear in mind that I propose to add this link to a PEP to every "New in version" line in the docs (progressively, working back in time). That's a lot of additional vertical space in the long run.

@cameron-simpson
Copy link
Author

Bear in mind that I propose to add this link to a PEP to every "New in version" line in the docs (progressively, working back in time). That's a lot of additional vertical space in the long run.

Of course, that also means we should reach an agreement about the form, because it is a lot of edits.

I distinctly want to add this information while minimising the physical space intrusion into the docs.

@cameron-simpson
Copy link
Author

Ah! The output feels a bit wrong to me; I think the versionadded note (with optional details) should be separate from the PEP note.

Hmm. Considering the separation side of things. I'll try to make a .. pepfor macro, see how it looks; that would potentially be helpful elesewhere as well (maybe, undecided yet). Though I'm still unhappy about the additional vertical space.

@cameron-simpson
Copy link
Author

cameron-simpson commented Sep 17, 2020

I'll try to make a .. pepfor macro, see how it looks; that would potentially be helpful elesewhere as well (maybe, undecided yet).

Ouch! What a can of worms. Sphinx is amazingly complex for what I'd imagined a simple case. Abandoned this for now.

However, on the theme of alternative approaches, might I show you this in the "Yield Expressions" section of reference/expressions.html:

bpo-41787--pep424-refs--yield-expressions

This has a "Changed in version 3.3" line in the same style as my proposed "Originally specified by PEP" note, and for contrast a much bulkier "See also:" section just below it. I prefer the former for the PEP reference, myself.


.. versionadded:: 3.4
Originally specified by :pep:`424`.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other places the wording is "Originally specified in PEP XXX" (in and not by).

@slateny
Copy link
Contributor

slateny commented Jan 10, 2023

For your example, 'changed in' comes with expectation of some explanation on what the changes are so text on the same line makes sense, but it's slightly less so for a 'new in'. That said, there are nonetheless current examples with the note being on the same line (though maybe slightly redundant in this case). There is also an example where the note on the PEP is indeed just on its own line, but if there isn't an established convention I think both cases are fine, regardless of the additional space.

I also do concur with Irit's comment in that since there's some existing phrasing that uses 'in' instead of 'by', might as well just swap it over for consistency.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting review docs Documentation in the Doc dir skip news
Projects
Status: Todo
Development

Successfully merging this pull request may close these issues.

8 participants