docstring-tailor 0.3.0__tar.gz → 0.3.1__tar.gz

{docstring_tailor-0.3.0 → docstring_tailor-0.3.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: docstring-tailor
-Version: 0.3.0
+Version: 0.3.1
 Summary: Formats Python docstrings to PEP 257 style with configurable line length.
 Author-email: Auke Bruinsma <afbruinsma@gmail.com>
 License: MIT License
@@ -556,7 +556,11 @@ Steps:
 
 ### 60 characters per line — The Minimalist Monk 🧘
 
-You believe every character has a purpose and every extra column is a personal failure 😤. You keep your docstrings short, your functions tiny, and your emotional attachment to whitespace surprisingly strong. You don't need room to explain your code because your code should be obvious. If a sentence doesn't fit in 60 characters, you simply rewrite the sentence until it does. Brevity is not a preference for you. Brevity is a lifestyle.
+You believe every character has a purpose and every extra column is a personal failure 😤. You keep your docstrings short, your functions tiny, and your emotional attachment to whitespace surprisingly strong. Variable names? Anything longer than two characters is wasteful bloat — x, y, z, and i are sufficient for any problem. Docstrings are memory theft; everything the code needs to say should be obvious from context or inferred through pure spiritual understanding 🙏. Why document when you could just make the code so minimalist that it transcends the need for explanation? Your motto: if it takes more than 60 characters to explain, the explanation itself is the bug, not the code.
+
+### 79 characters per line — The Precision Tuner ⚙️
+
+You didn't choose 79 characters; you derived it through first principles and a spreadsheet. You read every formatter's GitHub issues, every style guide's rationale, and you have strong opinions about why 80 is overrated but 78 is cowardice 😤. You've A/B tested readability on three different monitors, measured your own eye-tracking data, and lost sleep over whether \n counts toward the limit or not. You configure your linter to lint your linter, and you have a .editorconfig file that is longer than most people's actual code 📋. You know exactly why PEP 8 suggested 79 and you've defended this choice at dinner parties with the fervor of someone protecting their firstborn child 🛡️. You don't just use docstring_tailor; you've benchmarked it against seven alternatives and created a spreadsheet ranking their consistency. Your line length is not a preference—it's a thesis 📊. You sleep well knowing that you have optimized, and the universe is in perfect order, exactly 79 characters wide.
 
 ### 80 characters per line — The Digital Archaeologist 🦖
 
@@ -605,6 +609,7 @@ You don't wrap text because wrapping is a skill issue. You let photons travel un
 | `0.2.0` | 2026-06-07 | Feature update | <ul><li>Implemented the `detect-lists` parameter, adding support for unordered and ordered (numbered) lists in docstrings. When enabled, list structures are detected automatically and each list item is formatted onto its own line.</li><li>Introduced a declarative golden-file test framework for formatter validation. Test cases are now generated from parametrized templates using Cartesian-product expansion, significantly reducing boilerplate and improving scalability for configuration coverage.</li><li>Expanded this `README.md` with the 'API Overview', 'Release Notes', 'Example docstrings' and 'Roadmap' sections.</li><li>Test coverage: 75%</li></ul> |
 | `0.2.1` | 2026-06-11 | Feature update | <ul><li>Added the `-V`/`--version` command to the CLI.</li><li>Added the `--exclude` command to the CLI.</li><li>Added the `--diff` command to the CLI.</li><li>Added the 'Demo' part to to the `README.md`.</ul> |
 | `0.3.0` | 2026-07-20 | Feature update & bug fixes | <ul><li>Introduced a style-agnostic intermediate representation (IR) model and refactored parsing into an abstract base class hierarchy. Google and NumPy docstrings now parse into the same IR via `IndentationBasedParser` subclasses, enabling lossless conversion between styles. Structured list parsing is delegated to style-specific implementations to handle syntactic differences (Google's inline `name (type):` vs. NumPy's `name : type` on separate lines).</li><li>Refactored rendering to match the parser architecture: `DocstringRendererBase` (ABC) with style-specific subclasses that implement two hooks — section header formatting (Google's `Args:` vs. NumPy's `Parameters` + underline) and section body indentation rules (confirmed against numpy's own docstrings to keep bodies flush with headers, unlike Google). Keyword translation between styles happens automatically during conversion.</li><li>Code sections and Python REPL blocks now also can be created outside the 'Example(s)' section.</li><li>Fixed a bug when codeblock sections contain blank lines.</li><li>Fixed a bug when the docstring starts immediately with an (un)ordered list.</li><li>Removed `detect-lists` as CLI parameter, because the logic should always be applied if the docstring contains (un)ordered lists.</li><li>Changed behaviour for empty docstrings so that it consistent with Ruff.</li></ul> |
+| `0.3.1` | 2026-07-21 | Small fixes | <ul><li>The `style` parameter does not have a default argument anymore, instead it always has to be configured explicitly by the user.</li><li>Fixed a bug where one-line docstrings inside indented scopes (e.g. class or method bodies) were wrapped to multiple lines prematurely, due to indentation being counted twice when checking against the configured line length.</li> <li>Added an exception, consistent with Ruff, allowing a one-line docstring to exceed the configured line length by up to 3 characters when only the closing triple quotes would otherwise be pushed onto their own line. This prevents docstring_tailor and Ruff from repeatedly reformatting the same docstring back and forth when both are run as pre-commit hooks.</li></ul> |
 
 ## Roadmap
 

{docstring_tailor-0.3.0 → docstring_tailor-0.3.1}/README.md

@@ -523,7 +523,11 @@ Steps:
 
 ### 60 characters per line — The Minimalist Monk 🧘
 
-You believe every character has a purpose and every extra column is a personal failure 😤. You keep your docstrings short, your functions tiny, and your emotional attachment to whitespace surprisingly strong. You don't need room to explain your code because your code should be obvious. If a sentence doesn't fit in 60 characters, you simply rewrite the sentence until it does. Brevity is not a preference for you. Brevity is a lifestyle.
+You believe every character has a purpose and every extra column is a personal failure 😤. You keep your docstrings short, your functions tiny, and your emotional attachment to whitespace surprisingly strong. Variable names? Anything longer than two characters is wasteful bloat — x, y, z, and i are sufficient for any problem. Docstrings are memory theft; everything the code needs to say should be obvious from context or inferred through pure spiritual understanding 🙏. Why document when you could just make the code so minimalist that it transcends the need for explanation? Your motto: if it takes more than 60 characters to explain, the explanation itself is the bug, not the code.
+
+### 79 characters per line — The Precision Tuner ⚙️
+
+You didn't choose 79 characters; you derived it through first principles and a spreadsheet. You read every formatter's GitHub issues, every style guide's rationale, and you have strong opinions about why 80 is overrated but 78 is cowardice 😤. You've A/B tested readability on three different monitors, measured your own eye-tracking data, and lost sleep over whether \n counts toward the limit or not. You configure your linter to lint your linter, and you have a .editorconfig file that is longer than most people's actual code 📋. You know exactly why PEP 8 suggested 79 and you've defended this choice at dinner parties with the fervor of someone protecting their firstborn child 🛡️. You don't just use docstring_tailor; you've benchmarked it against seven alternatives and created a spreadsheet ranking their consistency. Your line length is not a preference—it's a thesis 📊. You sleep well knowing that you have optimized, and the universe is in perfect order, exactly 79 characters wide.
 
 ### 80 characters per line — The Digital Archaeologist 🦖
 
@@ -572,6 +576,7 @@ You don't wrap text because wrapping is a skill issue. You let photons travel un
 | `0.2.0` | 2026-06-07 | Feature update | <ul><li>Implemented the `detect-lists` parameter, adding support for unordered and ordered (numbered) lists in docstrings. When enabled, list structures are detected automatically and each list item is formatted onto its own line.</li><li>Introduced a declarative golden-file test framework for formatter validation. Test cases are now generated from parametrized templates using Cartesian-product expansion, significantly reducing boilerplate and improving scalability for configuration coverage.</li><li>Expanded this `README.md` with the 'API Overview', 'Release Notes', 'Example docstrings' and 'Roadmap' sections.</li><li>Test coverage: 75%</li></ul> |
 | `0.2.1` | 2026-06-11 | Feature update | <ul><li>Added the `-V`/`--version` command to the CLI.</li><li>Added the `--exclude` command to the CLI.</li><li>Added the `--diff` command to the CLI.</li><li>Added the 'Demo' part to to the `README.md`.</ul> |
 | `0.3.0` | 2026-07-20 | Feature update & bug fixes | <ul><li>Introduced a style-agnostic intermediate representation (IR) model and refactored parsing into an abstract base class hierarchy. Google and NumPy docstrings now parse into the same IR via `IndentationBasedParser` subclasses, enabling lossless conversion between styles. Structured list parsing is delegated to style-specific implementations to handle syntactic differences (Google's inline `name (type):` vs. NumPy's `name : type` on separate lines).</li><li>Refactored rendering to match the parser architecture: `DocstringRendererBase` (ABC) with style-specific subclasses that implement two hooks — section header formatting (Google's `Args:` vs. NumPy's `Parameters` + underline) and section body indentation rules (confirmed against numpy's own docstrings to keep bodies flush with headers, unlike Google). Keyword translation between styles happens automatically during conversion.</li><li>Code sections and Python REPL blocks now also can be created outside the 'Example(s)' section.</li><li>Fixed a bug when codeblock sections contain blank lines.</li><li>Fixed a bug when the docstring starts immediately with an (un)ordered list.</li><li>Removed `detect-lists` as CLI parameter, because the logic should always be applied if the docstring contains (un)ordered lists.</li><li>Changed behaviour for empty docstrings so that it consistent with Ruff.</li></ul> |
+| `0.3.1` | 2026-07-21 | Small fixes | <ul><li>The `style` parameter does not have a default argument anymore, instead it always has to be configured explicitly by the user.</li><li>Fixed a bug where one-line docstrings inside indented scopes (e.g. class or method bodies) were wrapped to multiple lines prematurely, due to indentation being counted twice when checking against the configured line length.</li> <li>Added an exception, consistent with Ruff, allowing a one-line docstring to exceed the configured line length by up to 3 characters when only the closing triple quotes would otherwise be pushed onto their own line. This prevents docstring_tailor and Ruff from repeatedly reformatting the same docstring back and forth when both are run as pre-commit hooks.</li></ul> |
 
 ## Roadmap
 

{docstring_tailor-0.3.0 → docstring_tailor-0.3.1}/makefile

@@ -45,7 +45,7 @@ git:
 
 # Run full workflow: format, type-check, test, clean, commit
 all:
-	uv run src/docstring_tailor/main.py format --line-length 80
+	uv run src/docstring_tailor/main.py format --style google --line-length 80
 	make ruff
 	make ty
 	make pytest

{docstring_tailor-0.3.0 → docstring_tailor-0.3.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "docstring-tailor"
-version = "0.3.0"
+version = "0.3.1"
 description = "Formats Python docstrings to PEP 257 style with configurable line length."
 authors = [{ name = "Auke Bruinsma", email = "afbruinsma@gmail.com" }]
 license = { file = "LICENSE" }

{docstring_tailor-0.3.0 → docstring_tailor-0.3.1}/src/docstring_tailor/cli_config.py

@@ -17,7 +17,6 @@ class DocstringStyle(str, Enum):
 
 
 SUPPORTED_STYLES = {DocstringStyle.google, DocstringStyle.numpy}
-DEFAULT_STYLE = DocstringStyle.google
 
 # Argument: '--line-length'
 LINE_LENGTH_MIN: int = 30

{docstring_tailor-0.3.0 → docstring_tailor-0.3.1}/src/docstring_tailor/main.py

@@ -16,7 +16,6 @@ import typer
 
 from docstring_tailor.cli_config import (
     DEFAULT_PATHS,
-    DEFAULT_STYLE,
     LINE_LENGTH_DEFAULT,
     LINE_LENGTH_MAX,
     LINE_LENGTH_MIN,
@@ -198,9 +197,18 @@ def format_command(
     resolved_paths, resolved_line_length, resolved_exclude, file_config = (
         _resolve_common_options(paths=paths, line_length=line_length, exclude=exclude)
     )
-    resolved_style = style or DocstringStyle(
-        file_config.get("style", DEFAULT_STYLE.value)
-    )
+
+    resolved_style = style or file_config.get("style")
+
+    if resolved_style is None:
+        typer.echo(
+            "Error: Docstring style not specified. "
+            "Pass --style on the command line or set 'style' in your config file "
+            "(pyproject.toml or docstring_tailor.toml)."
+        )
+        raise typer.Exit(code=1)
+
+    resolved_style = DocstringStyle(resolved_style)
 
     _validate_supported_style(resolved_style)
 

{docstring_tailor-0.3.0 → docstring_tailor-0.3.1}/src/docstring_tailor/renderer/base_renderer.py

@@ -552,10 +552,11 @@ class DocstringRendererBase(ABC):
         immediately without attempting a render.
 
         1. Determines the raw content: empty string, or the sole Paragraph's
-           text.
-        2. Normalizes internal whitespace to single spaces.
-        3. Rejects the one-line rendering if the delimited content exceeds the
-           wrap width.
+        text. 2. Normalizes internal whitespace to single spaces. 3. Rejects the
+        one-line rendering if the total physical line length exceeds the
+        configured line length by more than DOCSTRING_DELIMITER_LENGTH
+        characters. This allows up to 3 characters of overage (the closing
+        \"\"\") for Ruff compatibility in pre-commit hooks.
 
         Args:
             ir (list[DocstringNode]): Fully parsed and typed IR from a parser.
@@ -563,7 +564,8 @@ class DocstringRendererBase(ABC):
         Returns:
             one_line (str | None): The rendered one-line docstring including
                 triple-quote delimiters, or None if the IR does not qualify or
-                is too long to fit.
+                exceeds the line length by more than DOCSTRING_DELIMITER_LENGTH
+                characters.
         """
         if not ir:
             content = ""
@@ -579,7 +581,9 @@ class DocstringRendererBase(ABC):
             + 2 * DOCSTRING_DELIMITER_LENGTH
         )
 
-        if total_length > self._wrap_width:
+        # Allow up to DOCSTRING_DELIMITER_LENGTH characters of overage (the
+        # closing """) for Ruff compatibility in pre-commit hooks.
+        if total_length > self._line_length + DOCSTRING_DELIMITER_LENGTH:
             return None
 
         one_line = DOCSTRING_DELIMITER + normalized + DOCSTRING_DELIMITER

{docstring_tailor-0.3.0 → docstring_tailor-0.3.1}/uv.lock

@@ -119,7 +119,7 @@ toml = [
 
 [[package]]
 name = "docstring-tailor"
-version = "0.2.2"
+version = "0.3.1"
 source = { editable = "." }
 dependencies = [
     { name = "libcst" },