python: Implement version-agnostic Protocol types - #114
Conversation
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Coverage reportClick to see where and how coverage changed
This report was generated by python-coverage-comment-action |
||||||||||||||||||||||||
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Follows --include-main pattern Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
|
This PR may need update after #124 got merged, as the protocols may need to have the new |
|
#124 merged. Need to review this PR (may need few revision). Put to draft. |
Follow the updated test.ttl Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
prop_is_list() was independently reimplemented in cpp.py, golang.py, rust.py, and python.py. Move it to common.py and share it across all language renderers. Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Will split in another PR Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
|
@JPEWdev if you plan to release a new version, please go ahead with that. I just realized that the logic I currently used here to check class compatibility across versions is not working with SPDX 3.0.1 vs SPDX 3.1, due to the reliance on term IRIs. Now trying to find ways around but please don't take this as a blocker. The JSS alone is worth a release. |
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
|
The versioned IRI issue is now solved by allowing user to choose compact form of class to be used as a discriminator. Classes from SPDX 3.0.1 and SPDX 3.1 can now work with each other (as long as they use context document that produce similar compact form). |
Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
Use latest black on Python 3.14 Signed-off-by: Arthit Suriyawongkul <arthit@gmail.com>
This PR adds
src/shacl2code/lang/templates/python/protocols.py.j2template to generates Protocol structure types for classes in the generated bindings.Given two versions of a model (v1 and v2; v2 is backward compatible with v1) to shacl2code to generate Python bindings (one at a time), it will generate two bindings that look similar but v1.SomeClass and v2.SomeClass are considered distinct. They are not sharing a common parent type.
This makes it difficult for a downstream user who wants to write a function like:
Because if it defines
SomeClassasv1.SomeClass, it will be incompatible withv2.SomeClass(and vice versa).This PR provides the generation of
protocols.SomeClasswhich is a structural type that accepts any class with the same shape (has similar members), sov1.SomeClassandv2.SomeClasscan be both accepted, even they are unrelated.This function will work across all versions of the model (provided that they are keeping backward compatibility to previous versions -- not removing any members in newer versions):