It's certainly a trade-off, but the benefit of keeping the output as it is shown now in the docstrings (and so adopting scipy-doctest to be able to keep doing that also when updating numpy > 2) is that it gives less visual clutter in the example and focuses more on the message to show to the user.

If we show an example like:

>>> shapely.has_z(Point(0, 0))
False

the main message is that it returns False for a XY point. If this shows np.False_ (or np.float64(1.0) for 1.0), that feels like unnecessary clutter and potentially distracting the reader.

It's like putting a print(..) around each example, except for not doing that explicitly..

Pull Request Test Coverage Report for Build 13386052724

Details

• 23 of 31 (74.19%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.3%) to 87.764%

Totals
Change from base Build 13364938053:	0.3%
Covered Lines:	2618
Relevant Lines:	2983

💛 - Coveralls

If/when NumPy changes their docstrings, then I'd be convinced to change it here too. For instance, see numpy.sin where currently np.sin(np.pi/2.) shows 1.0 rather than np.float(1.0) as with modern versions of NumPy.

Also, I should note that scipy-doctest has an option dt_config.strict_check = True that does dtype checks where applicable, which is related to numpy/numpy@90c34cb. If we were to enable this feature, it would require changes like:

>>> shapely.get_coordinate_dimension(Point(0, 0))
np.int32(2)

but this option still relaxes np.float64(0.0) stuff as 0.0. But I don't think it's really important to most users that (e.g.) coordinate dimensions have a int32 type, so I didn't enable this feature. But perhaps it's more important for users to see (e.g.)

>>> shapely.get_srid(shapely.set_srid(Point(0, 0), 1234567890))
np.int32(1234567890)

But perhaps it's more important for users to see (e.g.)

That also doesn't seem that important to know the SRID is returned as an int32 vs int64? (SRID numbers are typically smaller numbers than the int32 limits)

I am going to merge those small suggestions, so I can merge this PR now to avoid another round of updating an fixing merge conflicts if I continue merging other PRs!

Thanks @mwtoews!