PEP 8 compliant notation/names

[sbenthall]

Originally in #857

The current standard for notation has been defined by NARK, which specifies the translation of mathematical notation into strings. This has complicated the adherence to Python notational conventions because these notational strings have been used as Python variable names. This is changing as of 0.10.8: now these strings are being used as keys in namespaces for model variable values and so on.

That creates an opportunity to streamline the 'mathematical notation' elements of HARK, with a couple of possibilities:

• Removing Now and Prev from model variable names
• reconsider the use of mattNwhiteCase for math variable names

[sbenthall]

EndOfPrdvPP -> end_of_prd_vpp ?

[sbenthall]

The first step on this which is:

• turn Python code to PEP 8 style
• except for the explicit mathematical terms, which are in NARK

[MridulS]

Didn’t we already run black against the codebase? (Or am I just imagining it)

…

On Fri 12. Feb 2021 at 16:37, Sebastian Benthall ***@***.***> wrote: The first step on this which is: - turn Python code to PEP 8 style - *except* for the explicit mathematical terms, which are in NARK — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#907 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABI5RFGMLGP3CTEEQVAGLLDS6VDKHANCNFSM4V7RQVAA> .

[sbenthall]

We did. The main thing that is out of compliance is the use of CamelCase instead of snake_case in a lot of places.

[sbenthall]

black does not check for that.

[MridulS]

Ah yeah! But I remember Matt/Chris having strong opinions against it?

[sbenthall]

I believe Matt original objected but has changed his mind since.

I was just on a call with Chris where I confirmed with him this plan.

This has been discussed in this EEP:

https://github.com/econ-ark/governance/issues

[llorracc]

Actually, this seems like a good instance for actually using the EEP process and taking it all the way to completion. Especially to get Matt's sign-off. What Seb proposed today was basically to keep the non-PEP8 names for mathematical objects, but move toward pep8ish names for purely programming objects. That sounded reasonable to me, but I guess it would be good to have its meaning fleshed out a bit. In particular, does this proposal involve renaming all of the model classes? Like, ConsIndShockModel, etc? Basically, that would break every single thing in the entire codebase. I'm not sure I'm on board for that, two weeks before we want to announce HARK 1.0. At a minimum, I'd want to be certain that everything we have is successfully pinned to a previous release of HARK and makes sure that release is the one that gets used.

…

On Fri, Feb 12, 2021 at 12:02 PM Sebastian Benthall < ***@***.***> wrote: I believe Matt original objected but has changed his mind since. I was just on a call with Chris where I confirmed with him this plan. This has been discussed in this EEP: https://github.com/econ-ark/governance/issues — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#907 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKCK73YT55YEWWN3K3DXKTS6VNLPANCNFSM4V7RQVAA> .

-- - Chris Carroll

[sbenthall]

In particular, does this proposal involve renaming all of the model classes?

No it does not.

Please see the discussion of this in the EEP.

https://github.com/econ-ark/governance/issues/5#issuecomment-656888010

[llorracc]

I'm confused.

I looked in the EEP. It says:

PEP8 is opinionated. The format of the names should match the programming role of the object.

Class names: CapWordsStyle aka CamelCase
Function and variable names: lower_case_with_internal_underscores
Class method names: same as functions

OK, so ConsIndShockModel.py is a package, and not any of these things.

But could you clarify whether when you said that we were going to leave alone "mathematical objects" did you mean for example ConsumerSolution etc? And the function defValueFuncs?

If not, what ARE some specific examples of things you'd like to change and about which you think there might be some controversy?

[sbenthall]

ConsumerSolution and IndShockConsumerType are the names of class names. As they are in CapWordsStyle, they would be unchanged in my proposal.

The function defValueFuncs is a function name. To be compliant with PEP 8, this would need to be changed to lower_case_with_underscores. For example, it could become def_value_funcs.

I am certainly not trying to make a controversial proposal. I am trying to make a proposal that will move us closer to PEP 8 compliance while acknowledging the limited time available before the 1.0 release.

An example of something that might be "left alone" is updateRiskyDstn. RiskyDstn is a term for a mathematical entity.
I could see a case for making it update_RiskyDstn, but would not insist on it at all.

[sbenthall]

Is ValueFuncs a mathematical name, i.e specified in NARK?
In that case it is a bad example of a function that would be changed.

A better example: prepareToSolve -> prepare_to_solve