Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-97

Allow PEP8 naming conventions in python style guide

    XMLWordPrintable

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None

      Description

      The LSST DM Python Style Guide mostly jives with PEP8, although it recommends camelCase over lowercase_with_underscores for methods, class attributes, and module names. This is contradictory with PEP8, which recommends that camelCase convention only be used when backwards compatibility is an issue.

      When a software product allows (e.g. pure python and no SWIG), I'd like to recommend we allow, and possibly encourage, PEP8 naming conventions.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness Tim Jenness added a comment -

            Good catch. This was informally accepted at Bremerton so long as code is migrated package by package rather than file by file. New code can use it. Flagging to Kian-Tat Lim as this is a coding standard issue.

            Show
            tjenness Tim Jenness added a comment - Good catch. This was informally accepted at Bremerton so long as code is migrated package by package rather than file by file. New code can use it. Flagging to Kian-Tat Lim as this is a coding standard issue.
            Hide
            ktl Kian-Tat Lim added a comment -

            I think there is a little bit of confusion as to what level this is intended to apply to.

            The simplest route to adoption is to say that it applies to independent top-level products (e.g. those built by Jenkins, or independent services such as those provided by SQuaRE) including all their first-party (LSST-developed) dependencies; each such product is either all PEP8-named or all camelCase-named. I think that several products have already gone this route. The problem with this is that it discourages sharing code.

            An alternative would be to say that it applies to new packages (or git repositories), which would have the option of being PEP8-named (in Python and C++). I think this has higher costs in terms of cognitive load and transition impacts.

            For either level, I'm not sure I really like the "allowed" and "encouraged" language. I think it's clearer for developers if we pick a stance and stick with it, even if we have (temporary) non-conformance. So I would be a bit happier if this were to say that all new products or packages must be PEP8-named.

            Transitioning existing code to PEP8-naming is a bit of a bigger deal, since it involves code in not just the package transitioning but also all packages dependent on it. It would help if good tools could be made available to assist this process.

            Show
            ktl Kian-Tat Lim added a comment - I think there is a little bit of confusion as to what level this is intended to apply to. The simplest route to adoption is to say that it applies to independent top-level products (e.g. those built by Jenkins, or independent services such as those provided by SQuaRE) including all their first-party (LSST-developed) dependencies; each such product is either all PEP8-named or all camelCase-named. I think that several products have already gone this route. The problem with this is that it discourages sharing code. An alternative would be to say that it applies to new packages (or git repositories), which would have the option of being PEP8-named (in Python and C++). I think this has higher costs in terms of cognitive load and transition impacts. For either level, I'm not sure I really like the "allowed" and "encouraged" language. I think it's clearer for developers if we pick a stance and stick with it, even if we have (temporary) non-conformance. So I would be a bit happier if this were to say that all new products or packages must be PEP8-named. Transitioning existing code to PEP8-naming is a bit of a bigger deal, since it involves code in not just the package transitioning but also all packages dependent on it. It would help if good tools could be made available to assist this process.
            Hide
            tjenness Tim Jenness added a comment - - edited

            We have been talking about this on the github PR for RFC-162. I think you have agreed to the following:

            • New packages must use PEP8 naming convention everywhere.
            • For existing packages, migrating the API to PEP8 should be done as part of the "pythonic APIs" RFC-81.

            I would also like to add

            • Local variables and internal functions/methods that are not part of the public API can now switch to using PEP8 on a file by file basis. These changes can be made a file at a time as people edit code normally when fixing flake8 issues.
            Show
            tjenness Tim Jenness added a comment - - edited We have been talking about this on the github PR for RFC-162 . I think you have agreed to the following: New packages must use PEP8 naming convention everywhere. For existing packages, migrating the API to PEP8 should be done as part of the "pythonic APIs" RFC-81 . I would also like to add Local variables and internal functions/methods that are not part of the public API can now switch to using PEP8 on a file by file basis. These changes can be made a file at a time as people edit code normally when fixing flake8 issues.
            Hide
            ktl Kian-Tat Lim added a comment - - edited

            I propose to resolve this RFC in the following way:

            Any package within lsst_apps (and its dependencies), meas_*, pipe_*, and obs_*, whether new or old, retain the current camelCase naming conventions for everything including internal-only variables and methods.  Anything else needs to be consistent within a top-level product as built by Jenkins or within a distinct service and is recommended to use PEP8 under_score naming conventions.

            Discussion will be permitted until 5 PM Monday, Jan. 23 so as not to soak up too much on-the-clock developer time.

            Show
            ktl Kian-Tat Lim added a comment - - edited I propose to resolve this RFC in the following way: Any package within lsst_apps (and its dependencies), meas_* , pipe_* , and obs_* , whether new or old, retain the current camelCase naming conventions for everything including internal-only variables and methods.  Anything else needs to be consistent within a top-level product as built by Jenkins or within a distinct service and is recommended to use PEP8 under_score naming conventions. Discussion will be permitted until 5 PM Monday, Jan. 23 so as not to soak up too much on-the-clock developer time.
            Hide
            ktl Kian-Tat Lim added a comment -

            Adopting as stated (applies to products outside Science Pipelines).

            Show
            ktl Kian-Tat Lim added a comment - Adopting as stated (applies to products outside Science Pipelines).

              People

              Assignee:
              bvan Brian Van Klaveren
              Reporter:
              bvan Brian Van Klaveren
              Watchers:
              Brian Van Klaveren, John Swinbank, Jonathan Sick, Kian-Tat Lim, Mario Juric, Michael Wood-Vasey [X] (Inactive), Nate Lust, Robert Lupton, Tim Jenness, Xiuqin Wu [X] (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Planned End:

                  Jenkins

                  No builds found.