Refactor peps.json logic into PEP class
#2585
Conversation
|
The following commit authors need to sign the Contributor License Agreement: Click the button to sign: |
|
I clicked through to sign the CLA with my GH username+ID email, and...
I'll try again in a few minutes. A |
|
@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 |
| @property | ||
| def full_details(self) -> dict[str, str]: |
There was a problem hiding this comment.
| @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.
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.
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:
numberis missing fromfull_details, which should just be addedtitleis 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)typeandstatusare 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 typesstatusadditionally has theApril Foolstatus 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.
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.
A (small) speed up as we only sort the large list of PEPs once.
A
There was a problem hiding this comment.
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
.authorsattribute with each author in turn, deleting the list.A