Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v201:call,call_result,datatypes: complete and corrected type annotations #562

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

malsyned
Copy link

@malsyned malsyned commented Jan 5, 2024

I groveled through the v2.0.1 spec and updated all of the type signatures to be complete and accurate to the best of my ability.

I did this to support some work I'm doing to make a variant of @on that converts the JSON back to Python objects, but I think it will be useful to anyone using the library with an IDE, so I'm submitting it as a separate pull request.

@malsyned
Copy link
Author

malsyned commented Jan 5, 2024

I think this change is a superset of #529 and contains all of those fixes.

@malsyned malsyned force-pushed the ocpp-2.0.1-payload-correct-types branch from ea3d8ca to b729d04 Compare January 11, 2024 17:25
@jerome-benoit
Copy link

jerome-benoit commented Jun 12, 2024

The PR contains at least a serious fix to total_cost type, which is a showstopper at implementing an OCPP2 server compliant with pricing regulation with that library. The rest of PR is also refining properly a bunch of types definition.

@malsyned
Copy link
Author

I rebased this so it will merge cleanly with master, and added the suggested additional type fix from @jerome-benoit. This should be good to go now.

@jainmohit2001 jainmohit2001 force-pushed the ocpp-2.0.1-payload-correct-types branch from 534be5d to d9d06e4 Compare October 1, 2024 12:29
@jerome-benoit
Copy link

jerome-benoit commented Oct 1, 2024

@OrangeTux, @Jared-Newell-Mobility, @jainmohit2001: is there a chance that trivial PRs such as that one making the developer experience way more comfortable while enforcing strong types get reviewed and merged?

@jainmohit2001
Copy link
Collaborator

jainmohit2001 commented Oct 16, 2024

HI @malsyned, can you help with the following question?
Let's say the charger sends an Authorize request to the central system, we have the following handler in place:

@on(Action.Authorize)
async def on_authorize(self, id_token: dict, *args, **kwargs):
    status = AuthorizationStatusType.accepted
    return call_result.Authorize(id_token_info={"status": status})

Currently we have the following signature for Authorize dataclass:

@dataclass
class Authorize:
    id_token_info: Dict
    certificate_status: Optional[str] = None
    custom_data: Optional[Dict[str, Any]] = None

What would happen when we change the signature of Authorize to the following:

@dataclass
class Authorize:
    id_token: datatypes.IdTokenType
    certificate: Optional[str] = None
    iso15118_certificate_hash_data: Optional[List[datatypes.OCSPRequestDataType]] = None
    custom_data: Optional[Dict[str, Any]] = None

Do I need to make any changes to my @on handler?
How should I benefit from the new signature for Authorize dataclass?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants