type safety

[vuthanhtung2412]

Hi team,
Is there anyway to enforce type safety to the Rest API response ? Below is my use cases

from pyorthanc import Orthanc
from pyorthanc import Modality

client = Orthanc("http://localhost:8042", username="demo", password="demo")

# Create modality connection
modality = Modality(client, "PACS_SERVER")

# Test connection with C-ECHO
if modality.echo():
    print("Successfully connected to PACS")

# Query studies with C-FIND
response = modality.find({"Level": "Study", "Query": {}})

print(response["answers"]) # I want type safety for this part

BTW, is this the most appropriate place to drop this kind of question ?

[gacou54]

Hi, thank you for your question.

This is indeed a good place for this kind of question.

response["answers"] is of type List[Dict] according to https://github.com/gacou54/pyorthanc/blob/main/pyorthanc/_modality.py#L171

However, the subtypes in the dictionary are not specified List[Dict[?, ?]], which is the subject of your question if I understand correctly (please correct me if I'm wrong).

Since the Orthanc class is automatically generated, we don't have any further details. It is my understanding that from the spec https://orthanc.uclouvain.be/api/orthanc-openapi.json, for most of the GET calls we can only assume it will respond a application/json. According to the tests, the format of response["answers"] is List[Dict[str, str]].
https://github.com/gacou54/pyorthanc/blob/main/tests/test_modality.py#L32

Is it because a type checker like mypy is complaining? Maybe adding the def find(self, ...) -> Dict[str, Union[List[Dict[str, str]], str]] type hint instead of def find(self, ...) -> Dict would fix this

[vuthanhtung2412]

However, the subtypes in the dictionary are not specified List[Dict[?, ?]], which is the subject of your question if I understand correctly (please correct me if I'm wrong).

It is indeed the subject of my question

Since the Orthanc class is automatically generated, we don't have any further details.

Is what you mean is all the class in pyorthanc is autogenerated from the openAPI specs ?

Is it because a type checker like mypy is complaining?

No, it is just me trying to get something more strictly typed like

@dataclass
class PACSQueryAnswer:
    SpecificCharacterSet: str
    AccessionNumber: str
    QueryRetrieveLevel: str
    RetrieveAETitle: str
    PatientID: str
    StudyInstanceUID: str

However, I think for this the OpenAPI specs also specify it as any

[gacou54]

Is what you mean is all the class in pyorthanc is autogenerated from the openAPI specs ?

My bad, I meant the Client and AsynClient classes are generated automatically from the openapi spec, and are the heart of all pyorthanc's functions/classes, which means that it is not always clear what the resulting types are in these functions. But for the answers, it should always be the same.

I like the idea of ​​using a dataclasses. My only concern is breaking PyOrthanc's API. I've seen that there are TypedDicts that shouldn't break the PyOrthanc API. Do you think it would be a good solution? In a future major release of PyOrthanc, I'd like to utilize dataclasses for all types, but for now, I prefer not to break the PyOrthanc API.

from typing import TypedDict

class PACSQueryAnswerDict(TypedDict):
    SpecificCharacterSet: str
    AccessionNumber: str
    QueryRetrieveLevel: str
    RetrieveAETitle: str
    PatientID: str
    StudyInstanceUID: str

[vuthanhtung2412]

IMO, I would prefer pydantic runtime validation, this can make the code extensible.

[vuthanhtung2412]

Thanks again for the thorough answer 🙌

[gacou54]

I think something like this could be interesting. Essentially, preserve the current behavior, but add actual typing.

@dataclass
class QueryAnswer:
    SpecificCharacterSet: str
    AccessionNumber: str
    QueryRetrieveLevel: str
    RetrieveAETitle: str
    PatientID: str
    StudyInstanceUID: str

    def __getitem__(self, key: str):
        return getattr(self, key)

    def keys(self):
        return self.__dict__.keys()

I'll keep this issue open to keep it in my mind since I won't have time to work on this this week.