Pull Request Test Coverage Report for Build 7929712003

Details

• 0 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall first build on python3.13 at 88.076%

Totals
Change from base Build 7929487664:	88.1%
Covered Lines:	2600
Relevant Lines:	2952

💛 - Coveralls

@musicinmybrain Thanks for looking into this! We don't yet have CI for Python 3.13, but if you can test it on your end that this passes, I think we are certainly happy to already merge it.

particularly with the unexplained extra_indent

That's maybe a bug to report to cpython? If I try with one of our docstrings with a .. note:: using Python 3.11, that additional indent isn't present.

I tried originally to form a simplified reproducer. For example, if I write foo.py:

class SomeClass:
    def func(self):
        """Docstring that will be mocked.
        A multiline.

        .. note:: 'func' requires at least GEOS {version}.

        Some description.
        """

and then do

python3.13 -c 'from foo import SomeClass; print(repr(SomeClass.func.__doc__))'

I get what I would expect,

"Docstring that will be mocked.\nA multiline.\n\n.. note:: 'func' requires at least GEOS {version}.\n\nSome description.\n"

Now that I’m returning to this after a few days, I see exactly what’s happening. The docstring modification algorithm runs on the introspected (i.e. after byte-compilation) docstring, and it assumes the indentation level is at least 2. Since the doc string has already had indents stripped, this isn’t a good assumption, but we end up with the note indented two spaces anyway.

It seems like the choice of 2 is just a tiny performance optimization, and we could get rid of the “extra indent” without breaking anything else by simply starting at 0. I’ll try it out.

I began by force-pushing with an improved comment reflecting the above analysis.

It seems like the choice of 2 is just a tiny performance optimization, and we could get rid of the “extra indent” without breaking anything else by simply starting at 0. I’ll try it out.

This approach appears to work as expected in my testing on Python 3.13 and 3.12. Updating this PR.

If you wanted to find the indent more concisely without an explicit Python loop (in exchange for adding an otherwise-unnecessary temporary copy of part of the docstring), you could instead write:

# Figure out the indentation level
indent = len(doc) - len(doc[position:].lstrip(" ")) - position

Sorry for the slow follow-up, but rebased and still passing, so going to merge this now (and include in shapely 2.0.3). Thanks again!