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?

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

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 from full_details, which should just be added
• title is truncated in details, 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 and status are truncated to one letter in details, which can easily be done in the caller's format string, and is uppercased, which it already is for all valid types
• status additionally has the April 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.

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.

A (small) speed up as we only sort the large list of PEPs once.

A

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