Instead of making this a property (especially when the otherwise similardetails, despite its name being a noun, is not), it would be clearer, more descriptive and conventional to have it be ato_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" withdetails , as it doesn't seem obvious without careful inspection howfull_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 ametadata property, with the existing one made private or renamed toheaders, or ato_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 bypep_zero_generator.writer.column_format, which just passes it toformat(), 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 added
• title 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 types
• status additionally has theApril Fool status normalized, which should be done for both

So the only changes needed to replacedetails withfull_details should be addingnumber, normalizing the April Fool status, and adding:.1 aftertype andstatus in thepep_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 andcreate_pep_json is called once both times in the same way

(Pedantic note: Other thancreate_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.)