Dr. Quinten Stokkink

Apparently the MutPy changes are not lost at all. https://github.com/Tribler/py-ipv8-mutation-libraries/issues/1#issue-771999920 In that case, we can clean everything up neatly.

Once https://github.com/Tribler/mutpy/issues/1 is resolved, this repo should make use of the sanitized fork. Then the approach of https://github.com/Tribler/py-ipv8/issues/1254#issuecomment-1896079690 could be followed to implement the GitHub Action.

The mutpy fork issue has now been resolved. An `.md` report can be generated with: ```bash bin/github_report.py --codebase ipv8 ```

It seems like we would ideally use a [`dataclass_transform`](https://docs.python.org/3/library/typing.html#typing.dataclass_transform). However, this was introduced in Python 3.11 but does exist in `typing_extensions`. The PyCharm [source code hints at the existence of...

Using `dataclass_transform` to annotate our custom dataclass-like decorator does not seem to work 😢 *Disclaimer: I may be doing something wrong though.*

I think I'll give up on typing this for now. Using arcane typing constructs, my best efforts have only produced "`dataclass` AND `Type[VariablePayload]`"-types so far. This is not good enough...

It seems that `vp_compile` is actually destroying the type info. These are my tests: ```python def acts_as_payload(inp: Payload) -> None: pass # --- @dataclass() class UserClass: a: bool with suppress(TypeError):...

As it turns out, PyCharm essentially voids class types. Perhaps even worse, the typing in docstrings works better than typing using `typing`. An example: ```python from __future__ import annotations from...

I'll keep this issue open for the long term but - short term - we should remove the `overwrite_dataclass` (also from the docs) because it doesn't do anything anymore. EDIT:...

After further investigation, given that this issue is actually not a typing issue from our side but an internal PyCharm issue instead, I'll close this issue after all. Secondarily, the...