feat: Add contrains handling for stubs generator.

[Masara]

Is your feature request related to a problem?

Currently code with contrains is not handled during the stubs generation. If possible, this feature should be added (Python only supports upper bound contrains).

Desired solution

# Python
class ClassA[T: str]:
	...

// Stubs
class ClassA<T> where {T sub String} {
	...
}

Additional Context (optional)

• https://peps.python.org/pep-0695/#upper-bound-specification
• https://peps.python.org/pep-0695/#summary
• https://github.com/Safe-DS/DSL/blob/4c61b8c18a50fc89f193ebbbaa66ef1743db9ee0/tests/resources/grammar/declarations/classes/good-with%20multiple%20constraints.sdstest

[Masara]

@lars-reimann It seems that Mypy is unable to parse constrains of the form

class A[T: str]: ...

I found the mypy module constraints.py, but there another form of constrain definition is explained:

class Constraint:
    """A representation of a type constraint.

    It can be either T <: type or T :> type (T is a type variable).
    """
   ...

But it seems like it is just an internal constrains solver, not a parser we could use.

[lars-reimann]

Can it handle the old syntax?

from typing import Generic, TypeVar

_T_co = TypeVar("_T_co", covariant=True, bound=str)

class ClassA(Generic[_T_co]):
    def method1(self) -> _T_co:
        ...

[Masara]

@lars-reimann Yes, mypy can handle this syntax. I will create a parser for this syntax.
How would invariance be defined? Like this:

_T_in = TypeVar("_T_in", str, int)

?

[lars-reimann]

Probably, yes. Regarding this issue, I was rather looking at the bound=str part, though.

[Masara]

@lars-reimann So, if we parse this code:

_T_co = TypeVar("_T_co", covariant=True, bound=str)
_T_con = TypeVar("_T_con", contravariant=True, bound=int)


class ClassA(Generic[_T_co, _T_con]):
        ...

would it result in these stubs

class ClassA where {
    PythonName("_T_co") TCo sub str,
    PythonName("_T_con") TCon super int
}

?

And invariance is not of importance for us, since its the standard case?

[lars-reimann]

No, the stubs would be

class ClassA<out TCo, in TCon> where {
    TCo sub String,
    TCon super Int
}

• You first have to declare the type parameters (in the <> after the class name).
• You have to add the variance to the declared type parameters - in for contravariance, out for covariant. For invariant type parameters, you write neither in nor out.
• In the constraint you have to translate the primitive type like str or int to their equivalent Safe-DS type.
• You can omit the @PythonName in this case, since we handle all type checking in Safe-DS and don't have to translate the type parameters back to Python.

[Masara]

@lars-reimann Could you also give me an example of a class with constructor parameters? I dont quite know at which place the curved brackets would be append.

[lars-reimann]

The v0.3.0 release of the VS Code extension has snippets. The class snippet generates the skeleton of a class:

Slightly reformatted & without a superclass:

class MyClass<>() where {
    // ...
} {
   // ...
}

Parameters are added inside the ().