fix: Some packages couldn't be analyzed

[Masara]

Closes #48

Summary of Changes

• Fixed the bug where some packages couldn't be analyzed because the Mypy build result could not be parsed from our side.
• Added TypeVarType as a _types.py class for type variables.
• Some bug fixes and refactoring

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (a84ec64) 98.19% compared to head (070100d) 98.26%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #51      +/-   ##
==========================================
+ Coverage   98.19%   98.26%   +0.07%     
==========================================
  Files          25       25              
  Lines        1882     1905      +23     
==========================================
+ Hits         1848     1872      +24     
+ Misses         34       33       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

🦙 MegaLinter status: ⚠️ WARNING

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ JSON	eslint-plugin-jsonc	2	0	0	2.1s
✅ JSON	jsonlint	2		0	0.28s
✅ JSON	npm-package-json-lint	yes		no	0.58s
⚠️ JSON	prettier	2	0	1	0.32s
✅ JSON	v8r	2		0	6.28s
✅ PYTHON	black	15	0	0	1.88s
✅ PYTHON	mypy	15		0	8.1s
✅ PYTHON	ruff	15	0	0	0.06s
✅ REPOSITORY	git_diff	yes		no	0.01s

See detailed report in MegaLinter reports
Set VALIDATE_ALL_CODEBASE: true in mega-linter.yml to validate all sources, not only the diff

MegaLinter is graciously provided by

[Masara]

@lars-reimann I didn't know how to handle type variables like _T = TypeVar("_T") so for now I created a new type class in _types.py.

[lars-reimann]

What is the problem with those type variables? They were the only way to define classes with type parameters prior to Python 3.12 (PEP 695). So, there is no need to represent type variables directly, but only when they are used as type parameters. And there is no need to distinguish the different means to define type parameters.

[Masara]

@lars-reimann So, if a type parameter is defined like this:

_type_var = TypeVar("_type_var")

it should not be shown in the Safe-DS stubs if its not used?

And here the _type_var variable should be shown in the stubs:

_type_var = TypeVar("_type_var")
def type_var_func(type_var_list: list[_type_var]) -> list[_type_var]: ...

?

Also, how should the stubs for type variables look like? Like this?

@PythonName("_type_var")
typeVar = "_type_var"

@Pure
@PythonName("type_var_func")
fun typeVarFunc(typeVarList: List<typeVar>) -> result1: List<typeVar>

[lars-reimann]

We treat type variables and the PEP 695 syntax identically. For the Python code you provided, the stubs would be

@Pure
@PythonName("type_var_func")
fun typeVarFunc<TypeVar>(typeVarList: List<TypeVar>) -> result1: List<TypeVar>

The syntax is identical to classes with type parameters: After the name you declare the type parameters and can then use them in the parameter and result list.

[Masara]

I moved the issue regarding the TypeVars to a new issue (#63) so we can close this PR. @lars-reimann could you check this PR and close?

[lars-reimann]

I'll make room for this later today.

[lars-reimann]

I'll approve this now, so we can move forward. In the future, however, please create PRs that fix a single bug/add a single feature and add an accurate description of what you try to accomplish. Otherwise, it's not possible to determine whether a PR really works.

[lars-reimann]

🎉 This PR is included in version 0.2.0 🎉

The release is available on:

• v0.2.0
• GitHub release

Your semantic-release bot 📦🚀