Module 02: cover the underscore-prefix 'private/internal' convention

Open Beginner friendly
#40 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-2 days
Newbie friendliness
88/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Quiet
Tech stack
python
Domain
documentation

Research direction

Start in 02_function_classes.qmd around the naming-conventions section and review the existing mikeio.pfs._pfssection.PfsSection example. Add the underscore-prefix, all, re-exporting, and double-underscore guidance, then update the Breaking changes slide in 07_packaging.qmd with the public-API qualification and a cross-reference. Done means both modules clearly connect internal-name conventions to versioning.

Written by the indexing model from the issue text.

Description

Module 02 (02_function_classes.qmd) teaches Python naming conventions but does not cover the leading-underscore convention for internal/private names. This came up in practice: a user upgraded a dependency, found that several _-prefixed functions had been removed, and was upset — not realising those were never part of the public API.

The breaking-changes slide in 07_packaging.qmd (Removing a function / Renaming / Changing signature → bump major) is the counterpart to this: removing a _private function is not a breaking change. Worth a forward reference between the two modules.

Suggested content for module 02

Add a slide near the existing naming-conventions section (around 02_function_classes.qmd:802) covering:

  • _foo signals internal — not part of the public API
  • Consumers who import underscore-prefixed names do so at their own risk
  • Maintainers may change/remove them without bumping the major version
  • __all__ in __init__.py to declare the public surface
  • Re-exporting internals into the package namespace (the existing mikeio.pfs._pfssection.PfsSection example at 02_function_classes.qmd:795 is a natural lead-in)
  • Double-underscore (__name) name mangling is a separate thing — mention briefly to avoid confusion
Cross-reference

Update the "Breaking changes" slide in 07_packaging.qmd to note that the rules apply to the public API only, with a pointer back to module 02.

See PEP 8 — Naming Conventions / Public and internal interfaces.

Dominant language
Jupyter Notebook
Stars
8
Forks
1
Avg merge
4m
Merged PRs (30d)
1

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DHI/python-package-development

All issues in DHI/python-package-development

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.