From my regular expression foo, those are the only 9 case whereas there
are about ~2000 usage that do not have spaces.

While this is ok with docutils/sphinx, it does not seem to be
documented, and that means that other parsers will see that as comments,
leading to for example improper syntax highlighting.

This make it also a tiny bit harder to develop alternative rst parsers.

Fixes #19897

The 2nd return value of the following methods/functions were badly
formatted and the list was all appearing in a single line. Changed them
to separate points which are rendered nicely.
 - numpy.polyfit
 - numpy.ma.polyfit
 - numpy.polynomial.polynomial.polyfit
 - numpy.polynomial.polynomial.Polynomial.fit
 - numpy.polynomial.chebyshev.chebfit
 - numpy.polynomial.chebyshev.Chebyshev.fit
 - numpy.polynomial.hermite.hermfit
 - numpy.polynomial.hermite.Hermite.fit
 - numpy.polynomial.hermite_e.hermefit
 - numpy.polynomial.hermite_e.HermiteE.fit
 - numpy.polynomial.laguerre.lagfit
 - numpy.polynomial.laguerre.Laguerre.fit
 - numpy.polynomial.legendre.legfit
 - numpy.polynomial.legendre.Legendre.fit

Also fixed erroneous links to `numpy.full` which were actually referring
to the `full` argument. Changed those to code strings (double backticks)
from single backticks.

Also fixed formatting issues in the 3rd return value of numpy.polyfit
(and hence also numpy.ma.polyfit).

* DOC: Adjust polyfit doc to clarify the meaning of w

cov='unscaled', in particular, had inconsistently referred to a weight
of 1/sigma**2, while the doc for w says it should be equal to 1/sigma.
This change clarifies w to comport with more typical meanings of
weights in weighted least squares, and makes clear that cov='unscaled'
is appropriate when the weight w**2 = 1/sigma**2.

See Issue #5261 for more discussion of the errors/confusion in
the previous doc string.

* Update doc text for w in all polynomial module fit functions

Co-authored-by: Stefan van der Walt <sjvdwalt@gmail.com>
Co-authored-by: Ross Barnowski <rossbar@berkeley.edu>

* replace superfluous single-character regex character
classes with their literal string equivalents; this
avoids the overhead associated with a character class
when there's only a single character enclosed (so there's
no benefit to the class overhead)

* for more information see:
Chapter 6 of:
Friedl, Jeffrey. Mastering Regular Expressions. 3rd ed.,
O’Reilly Media, 2009.

This update a coupe of references (single backticks) that actually are not to
verbatim/code (double backticks); and a couple of verbatim to reference
when they do actually exists and can be resolved in context.

I probably missed other; and stayed simple but spoted a few other
inconsistencies that I did not fix:

  - some ``...`` could actually be :math:`...` but not always clear if
  it would be better.
  - some intervals are [``...``], other are ``[...]``

I guess they could be discussed individually; it was mostly the failing
references that bothered me.

Co-authored-by: Eric Wieser <wieser.eric@gmail.com>

Fixes gh-16354. Previously np.poly1d(z).coeffs.dtype would always
be np.float64 for zero array z, regardless of z's dtype.