Is there a good reason to have all these newlines? I think they make the code more unreadable.

Got rid of the ones after the argument lists. The ones before the argument list are present to make code generation simpler (we can just always indent by 8); note that previously the calls had sometimes "weird" indentations.

Why make this a class?

because str(parameter) calls repr(default), so that's how we override its output?

ah, understand now.

Is there a reason to put all the arguments on a new line. This looks rather unusual.

If it's just because of the text wrapping, you could pass initial_indent=' ' * (len(func) + 5) to text_wrapper.fill(). Then lstrip() or slice to [len(func)+5:] so that the first line has an appropriate length to fit after def thefunc(.
Even simpler, pass initial_indent='def thefunc(' to text_wrapper.fill().

It makes the autogeneration quite a bit simpler (specifically to properly wrap the first line -- the linewrapping code actually doesn't know ).
I would argue that while we want "reasonable" style for this autogenerated code, we shouldn't overthink it either...

Then you end up with

def some_long_function(some_long_arg_list, ...
        some_more_args, etc)

which is not optimal either (you'd either want to align some_more_args under some_long_arg_list, or have a newline after the parenthesis).
The first solution is... honestly not worth it IMO.

That's actually what I wanted. But not anymore after rechecking PEP-0008. 😄

I'm fine with all args on new line for longer signatures. For short ones see my other comment.

Only wrap for longer signatures by making this conditional:

if MAX_PREFIX + len(func) + len(sig) >= 80:

MAX_PREFIX is probably 18 (for __ret = gca().).

Sorry for being a bit picky, but users will see these if they look at the source, e.g. via ?? in ipython or if we plan to link the source in the docs in the future.

feel free to push the change to my branch

Honestly I think that when the source looks like

In [1]: plt.errorbar??
Signature: plt.errorbar(x, y, yerr=None, xerr=None, fmt='', ecolor=None, elinewidth=None, capsize=None, barsabove=False, lolims=False, uplims=False, xlolims=False, xuplims=False, errorevery=1, capthick=None, *, data=None, **kwargs)
Source:   
@docstring.copy_dedent(Axes.errorbar)
def errorbar(
        x, y, yerr=None, xerr=None, fmt='', ecolor=None,
        elinewidth=None, capsize=None, barsabove=False, lolims=False,
        uplims=False, xlolims=False, xuplims=False, errorevery=1,
        capthick=None, *, data=None, **kwargs):
    return gca().errorbar(
        x=x, y=y, yerr=yerr, xerr=xerr, fmt=fmt, ecolor=ecolor,
        elinewidth=elinewidth, capsize=capsize, barsabove=barsabove,
        lolims=lolims, uplims=uplims, xlolims=xlolims,
        xuplims=xuplims, errorevery=errorevery, capthick=capthick,
        data=data, **kwargs)
File:      ~/src/extern/matplotlib/lib/matplotlib/pyplot.py
Type:      function

the biggest issue is not with an extra newline, but that that's a useless source...

We could set __wrapper__ to the inner function so that getsource points to Axes.errorbar, but that may be confusing for functions that do call sci() with the return value...

No doubt not quite useful, but technically and style-wise correct. That's ok by me. I wouldn't set __wrapper__.

My point was more towards the short ones like

def table(
        **kwargs):
    return gca().table(
        **kwargs)

which should be (and is now with my push to your branch)

def table(**kwargs):
    return gca().table(**kwargs)

len('def ' + func + sig)

I think you can merge after this (effectively there's been two review approvals) (or even without fixing it if you don't want to).

I thought I won't construct a new string. But you're right. This is unneccesary micro-optimization.

Ok, will merge after CI pass, or do it yourself if you are around more early than me.