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

Graph.__getitem__ runtime type checking for slices breaks working code #3037

Open
tgbugs opened this issue Jan 15, 2025 · 1 comment
Open

Comments

@tgbugs
Copy link
Contributor

tgbugs commented Jan 15, 2025

The changes in
c37d399#diff-a8bea910ef28d48bce0a390d9ab24c55ac32f1c9a39d9cd215224e5447b70c83R709 break working code.

The type of the instance being passed does not matter in this context because the only thing that matters is whether or not the instance being passed is in the graph. Historically this means that code could pass strings, tuples, etc. to the slice and rdflib would find there were no triples containing that value and move along. This behavior is desirable (and correct) for a wide variety of dynamically typed code.

The recently added asserts can be placed behind an option to only enforce runtime type checking for those that want it in the same way that e.g. Graph.subject_objects does not force runtime asserts on consuming libraries. (In effect all the change does is force users to switch away from the convenient slice notation and to the more verbose Graph.subjects, ... Graph.predicate_objects functions.)

tgbugs added a commit to tgbugs/pyontutils that referenced this issue Jan 15, 2025
@ashleysommer
Copy link
Contributor

Thanks @tgbugs
There was a release mistake, those typing/assert changes from main branch were not meant to be released in v7.1.2. This will be rectified in the upcoming v7.1.3 release.

You're right, these asserts should be put behind a if TYPE_CHECKING:, we will make that fix in main, so this regression does not make it into the v8.0 release.

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

No branches or pull requests

2 participants