GeezerVison

Deferring the call to inspect.signature to create __doc__ might also speed up the dataclasses creation a bit. e.g. here's what I see in a cProfile of the _colorize module which uses dataclasses heavily (on main branch)

$ ./python -m cProfile -m _colorize | head 20
         5604 function calls (5484 primitive calls) in 0.007 seconds

   Ordered by: cumulative time

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      9/1    0.004    0.000    0.007    0.007 {built-in method builtins.exec}
        1    0.000    0.000    0.007    0.007 <string>:1(<module>)
        1    0.000    0.000    0.007    0.007 <frozen runpy>:199(run_module)
        1    0.000    0.000    0.007    0.007 <frozen runpy>:65(_run_code)
        1    0.000    0.000    0.007    0.007 _colorize.py:1(<module>)
        7    0.000    0.000    0.006    0.001 dataclasses.py:1432(wrap)
        7    0.000    0.000    0.006    0.001 dataclasses.py:986(_process_class)
        7    0.000    0.000    0.004    0.001 dataclasses.py:478(add_fns_to_class)
        4    0.000    0.000    0.001    0.000 inspect.py:3343(signature)
        4    0.000    0.000    0.001    0.000 inspect.py:3056(from_callable)
     12/4    0.000    0.000    0.001    0.000 inspect.py:2437(_signature_from_callable)
        4    0.000    0.000    0.001    0.000 inspect.py:2331(_signature_from_function)
    71/11    0.000    0.000    0.000    0.000 annotationlib.py:907(get_annotations)
        8    0.000    0.000    0.000    0.000 dataclasses.py:541(__annotate__)
     17/9    0.000    0.000    0.000    0.000 annotationlib.py:1114(_get_and_call_annotate)

I believe we should add a NEWS entry, because it is user-facing change (at least in the performance terms).

As a side effect that may be worth noting, deferring __doc__ generation also 'fixes' the output for self referential dataclasses¹.

@dataclass
class Example:
    examples: list[Example]

print(Example.__doc__)

Before:

"Example(examples: list[ForwardRef('Example', is_class=True, owner=<class '__main__.Example'>)])"

PR:

'Example(examples: list[__main__.Example])'

Every dataclass is getting its own _AutoDocString instance, could they share the same instance?

Following on from this, the re and copy imports could also potentially be deferred, copy is only used in some cases for the serialization methods and re is only used for string annotations.

Deferring re only makes sense if inspect is also deferred as inspect currently eagerly imports it (I see you have a PR to change that too though).

could they share the same instance?

They could; that would be nice.

Every dataclass is getting its own _AutoDocString instance, could they share the same instance?
Following on from this, the re and copy imports could also potentially be deferred, copy is only used in some cases for the serialization methods and re is only used for string annotations.

Done, thank you for the suggestions!
The lazy import or re is a bit more annoying since it is used to define a global compiled regex.
I am not sure I can judge whether the extra complexity is worth it --- the module will be imported as soon as you have e.g. from __future__ import annotations anywhere where dataclasses are defined.

Now the import time is dominated only by the "annotationlib" module

EDIT: Ugh, GitHub, you okay? The pushed new commits are still not appearing on the PR.

I am not sure I can judge whether the extra complexity is worth it --- the module will be imported as soon as you have e.g. from __future__ import annotations anywhere where dataclasses are defined.

Ideally with the new annotations, uses of __future__ annotations will become less common and so they won't need the import. Modules like _colorize should already benefit as they don't use __future__ annotations.

I'm not sure we should mix changes for _MODULE_IDENTIFIER_RE and __doc__ in one PR. But I'm not an expert here.

@danielhollas If you open a new PR with the lazy imports and global regex I'm happy to merge those. I'd prefer someone else to review the autodoc stuff.

@hugovk worth noting as it was one of the driving forces behind this that you lose a chunk of the benefit in _colorize without the autodoc stuff unless you write docstrings for the remaining dataclasses without them. The lack of docstring will trigger the inspect import.

One way of encouraging people to document their classes I guess 🙂 .

@danielhollas If you open a new PR with the lazy imports and global regex I'm happy to merge those. I'd prefer someone else to review the autodoc stuff.

Thanks, I could do, but note that deferring re without deferring inspect is pointless since inspect imports re as well. (and it also wouldn't help _colorize since re is imported there as well). If you think splitting these two changes would help with the review I'll do it, but I think a more impactful thing here would be to tag somebody who you think should review this.

This is a good improvement over main.

Here's importing _colorize on main vs. this PR (macOS optimised build):

	main	PR
import _colorize	13 ms	7 ms
import dataclasses	6 ms	2 ms
Execute _colorize	6 ms	4 ms

Thanks, I could do, but note that deferring re without deferring inspect is pointless since inspect imports re as well. (and it also wouldn't help _colorize since re is imported there as well).

I was wrong, I forgot that I made re lazy in inspect recently in #144756 😅 I've split the re and copy lazy imports in #148379. I will rebase this PR once that one is merged.

Alright, #148379 has been merged (thanks Hugo!) so this PR is now only about lazy importing inspect module.

After merging main, _colorize module no longer imports re. Here's a comparison on this PR:

versus main

Hi all, just a note that I will be away for two weeks starting 1st of May.
It would be great to get this merged before beta, since I don't think this would count as a "bugfix". While I am away, please feel free to push to this branch if any changes are needed.