-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Refactor peps.json
logic into PEP class
#2585
Conversation
The following commit authors need to sign the Contributor License Agreement: |
@hugovk how can we turn these comments off? A |
These are called "GitHub Checks": https://docs.codecov.com/docs/github-checks Let's try disabling by putting this in github_checks:
annotations: false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a solid change overall, and a step toward further single-sourcing PEP header parsing. I did have a few comments/suggestions, though.
@property | ||
def full_details(self) -> dict[str, str]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@property | |
def full_details(self) -> dict[str, str]: | |
def to_dict(self) -> dict[str, str]: |
Instead of making this a property (especially when the otherwise similar details
, despite its name being a noun, is not), it would be clearer, more descriptive and conventional to have it be a to_dict()
method, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I prefer the internal consistency of details / full_details, but not a big issue.
PEP.details
will become a property under the refactoring work needed for subindices, I'm pretty sure, although again minor.
A
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, I'm not sure why it needs to be a property, but that's really just bikeshedding. What confused me more was the "consistency" with details
, as it doesn't seem obvious without careful inspection how full_details
differs from it, nor what callers should expect it to do.
However, that got me thinking: It would seem to me that there should only be one attribute (whether a metadata
property, with the existing one made private or renamed to headers
, or a to_dict()
method) that contains the PEP's metadata as a dict, and selecting specific attributes the caller wants to use and any specialized output-specific reformatting it needs it should be the callers concern, rather than the PEP class.
This shouldn't be that much to unify them; as it stands now, details
is only used by pep_zero_generator.writer.column_format
, which just passes it to format()
, and so the items it doesn't use are simply discarded. Otherwise, the only differences are:
number
is missing fromfull_details
, which should just be addedtitle
is truncated indetails
, which can be done by the caller or better yet just dropped (since many non-truncated titles and those with many authors already extend to two lines anyway, so the space may as well be used to just show the full title, since only one PEP title is longer than 79 characters which still fits easily on two lines)type
andstatus
are truncated to one letter indetails
, which can easily be done in the caller's format string, and is uppercased, which it already is for all valid typesstatus
additionally has theApril Fool
status normalized, which should be done for both
So the only changes needed to replace details
with full_details
should be adding number
, normalizing the April Fool status, and adding :.1
after type
and status
in the pep_zero_generator.writer.column_format
format string.
json_path = Path(app.outdir, "api", "peps.json").resolve() | ||
json_path.parent.mkdir(exist_ok=True) | ||
json_path.write_text(create_pep_json(peps), encoding="utf-8") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I really understand the pressing need to rewrite all this when there were no functional changes in or near this line, and the previous form was perfectly valid and does exactly the same thing...it just seems like churn to me, but maybe I'm missing something important here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A (small) speed up as we only sort the large list of PEPs once.
A
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't follow, sorry. Maybe I'm missing something, but I don't see how any of the changes here have anything to do with that, as no sorting is performed within this block and create_pep_json
is called once both times in the same way
(Pedantic note: Other than create_pep_json()
is not bound to a name first before using it, which saves a few hundred kB of memory for the few ≈milliseconds it is alive while the path is checked, and perhaps on the order of microseconds on the fast local name lookup.)
(Doing a close/re-open to trigger the CLA bot.) |
(Doing a close/re-open to trigger the CLA bot. It was green on python/cpython#93468 and python/cpython#93564.) |
@hugovk Sadly I think that's as I was a co-author not the primary committer. (Which indicates that the CLA bot probably needs to be more thorough actually, I guess) A |
@JelleZijlstra and this one too please! A |
Factored out of #2579, simplifying the processing in
pep_index_generator.py
.This also fixes a logic bug, as currently the author concatenation overwrites the
.authors
attribute with each author in turn, deleting the list.A