Gp/update python#16
Conversation
mhasself
left a comment
mhasself
left a comment
There was a problem hiding this comment.
Thanks -- a few notes, but press forward!
| the cost of maintaining and sharing code. | ||
|
|
||
| For these reasons, it is the language SO will use the most for its codebase. Any | ||
| other language choise should be either for a very specific use case, or for |
| Overview | ||
| ======== | ||
|
|
||
| Python is a high-level laanguage that is widely used in the scientific computing |
| libraries. It is also highly portable and readable which significantly reduces | ||
| the cost of maintaining and sharing code. | ||
|
|
||
| For these reasons, it is the language SO will use the most for its codebase. Any |
There was a problem hiding this comment.
Restate "+data analysis+ codebase" or "+scientific computing+ codebase". For web front-end, e.g., we obviously don't insist on python.
| 2. Function names should be in camelCase, e.g. `myFunction`. | ||
| 3. Variable names should be in snake_case, e.g. `my_variable`. | ||
| 4. Constants should be in ALL_CAPS with underscores, e.g. `MAX_SIZE`. | ||
| 5. Namespaces should be in snake_case, e.g. `my_namespace`. |
There was a problem hiding this comment.
Instead of namespace, put module / submodule, here?
| @@ -69,15 +150,12 @@ We will accept any standard that meets the following criteria: | |||
| - nicely formatted text in auto-generated documentation using Sphinx | |||
|
|
|||
| We strongly recommended that SO codes use either the `numpy | |||
|
|
||
| We strongly recommended that SO codes use either the `numpy | ||
| style`_ or the `google style`_ for docstrings. These two styles are | ||
| style`_ as it is widely used to scientific Python packages, from numpy to astropy. |
| The CI check must pass before a pull request can be merged. Similarly, you can | ||
| set the CI to run linter check to verify that the code is formatted according | ||
| to the style guide. | ||
|
|
There was a problem hiding this comment.
Add a note that running CI on private repos costs money; another reason to keep code public / keep tests fast...
BrianJKoopman
left a comment
BrianJKoopman
left a comment
There was a problem hiding this comment.
I know I wasn't requested to review, and it already got merged, but I gave it a quick read and noticed a couple of things I wanted to comment on.
| developers confidence that individual components are correct before | ||
| combining them. | ||
|
|
||
| All codeabases regardless of programming language should include unit tests. |
There was a problem hiding this comment.
| All codeabases regardless of programming language should include unit tests. | |
| All codebases regardless of programming language should include unit tests. |
|
|
||
| We will utilize the following naming conventions: | ||
| #. Class and struct names should be in PascalCase, e.g. `MyClass`. | ||
| #. Function names should be in camelCase, e.g. `myFunction`. |
There was a problem hiding this comment.
PEP8 is for function names to use snake_case, no? camelCase in places where it's used already. Maybe we have a mix of uses -- ocs/socs use snake_case.
|
|
||
| There are several tools and methods to automatically generate version numbers | ||
| for Python packages. Three of the most popular are `versioneer`_, | ||
| `setuptools_scm`_ and `hatchling`_. |
There was a problem hiding this comment.
I'd probably instead link directly to hatch-vcs -- hatchling is the build backend, and doesn't natively do automatic versioning.
|
@BrianJKoopman thank you, I'll make the changes. |
3 participants
No description provided.