You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: languages/python.md
+14-15Lines changed: 14 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,11 +17,17 @@ Note: it's important that you follow all of the setup instructions in the templa
17
17
18
18
If you notice anything that needs to be updated in either of the templates, please submit a PR!
19
19
20
+
## Python Project Specification
21
+
22
+
The [Python Project Specification](https://github.com/MITLibraries/spec-python-projects) repository is a declarative standard for Python projects. It defines the tooling, configuration, file structure, and workflow targets that a compliant project should have. The [SPECIFICATION.md](https://github.com/MITLibraries/spec-python-projects/blob/main/SPECIFICATION.md) file in that repository is designed to be a living document with fairly constant updates.
23
+
24
+
Where this page provides general principles and recommendations, the specification aims to provide auditable, concrete requirements, e.g. `pyproject.toml` configuration, Makefile targets, pre-commit hooks, CI workflows, Dockerfile patterns, etc.
25
+
20
26
## Style and coding Conventions
21
27
22
28
In general, you should follow [PEP 8](https://www.python.org/dev/peps/pep-0008/) and [PEP 257](https://www.python.org/dev/peps/pep-0257/). Unless otherwise stated here, assume those two guidelines are in effect.
23
29
24
-
If you are providing function docstrings, use [reST](http://docutils.sourceforge.net/rst.html). In addition to a description of what a function does, you should document the parameters:
30
+
If you are providing function docstrings, use [Google style](https://google.github.io/styleguide/pyguide.html#38-comments-and-docstrings). In addition to a description of what a function does, you should document the parameters:
25
31
26
32
```python
27
33
defwidgetize(widget):
@@ -30,7 +36,8 @@ def widgetize(widget):
30
36
This ensures that the widget conforms to the strict standards
31
37
governing conformant widgets.
32
38
33
-
:param widget: a widget what needs widgetizing
39
+
Args:
40
+
widget: A widget what needs widgetizing.
34
41
"""
35
42
36
43
standardize(widget)
@@ -40,25 +47,17 @@ def widgetize(widget):
40
47
41
48
Our standard Python code checkers in all repositories include:
These tools should be used during development and are run automatically in Github Actions during CI. They are all included in the template repositories listed above, and have integrations for common code editors to allow automatic checking and reformatting during development.
50
55
51
-
The linters are usually run together with the `make lint` command in a project's Makefile. See the template repositories for examples.
56
+
The linters are usually run together with the `make lint` command in a project's Makefile.
52
57
53
58
## Dependencies
54
59
55
-
Use [Pipenv](https://pipenv.readthedocs.io/en/latest/) to manage dependencies for Python applications. If there's some reason you need to support pip, then you should still manage dependencies with pipenv, but generate your `requirements.txt` file as needed with:
56
-
57
-
```
58
-
pipenv requirements > requirements.txt
59
-
```
60
-
61
-
If you are creating a Python library, [Poetry](https://python-poetry.org/) is the preferred package and distribution manager.
60
+
Use [uv](https://docs.astral.sh/uv/) to manage dependencies for Python applications. Dependencies should be declared in `pyproject.toml` and locked with `uv lock`.
0 commit comments