[rr-]

Every style splits the optional mark and the default off a param's type. Once that happens, nobody can tell what the docstring actually said:

>>> param = parse("Short.\n\nParameters\n----------\nx : int, default 1\n    X.").params[0]
>>> param.type_name, param.is_optional, param.default
('int', True, '1')
>>> param.raw_type_name
'int, default 1'

Users who compare a docstring against the code, like linters checking types against annotations, need the original text. pydoclint's fork of this library added the same field for Numpydoc. Here it covers all four styles:

• ReST: :param str? x: and :type x: int, optional
• Google: x (int, optional):
• Numpydoc: x : int, optional
• Epydoc: @type x: int, optional

raw_type_name is None when no type is written. Return types are never split, so returns don't get the field. Compose still builds the type from type_name, is_optional and default, so composed output stays the same.

Case files show raw_type_name only where it differs from type_name. That adds 478 lines to 167 case files: 137 corpus, 11 numpydoc, 9 google, 6 epydoc, 3 rest, 1 auto. By command: 289 parse numpydoc, 163 parse google, 18 parse epydoc, 7 parse rest, 1 parse auto. No existing line changes.

Parity against main, with the new field ignored: 0 of 29,074 docstrings differ.

Bench on 3.8: parse is 0.99–1.01x of main.