Allow custom store implementations to not inherit from rdflib.store.Store #1538
ashleysommer
started this conversation in
Ideas
Replies: 2 comments
|
Maybe the best option would be to just invert this logic: Lines 325 to 329 in ab31c5e i.e., if it is a string, lookup the plugin, if not, just proceed as is. There is also https://docs.python.org/3/library/typing.html#typing.runtime_checkable - but that would be best used when no other option is available/appropriate. Something like |
0 replies
|
I don’t think the just-in-time registration’s a workaround: that’s the expected solution, as per other parsers and serialisers’ registration. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Opening this as a discussion topic.
Currently, when instantiating a
Graphinstance with a pass-instoreinstance, thestoreparameter must be either:rdflib.store.Store, orSee:
rdflib/rdflib/graph.py
Lines 325 to 329 in ab31c5e
However, I've twice encountered the situation where I want to pass in a store that looks like and acts like a
rdflib.store.Store(via duck-typing) but does not inherit fromrdflib.store.Store.Eg, this doesn't work:
This situation, the Graph constructor sees that
MySpecialStoredoes not inherit fromrdflib.store.Storeso it uses that as a lookup key to find a plugin, and fails because it is not a valid lookup key.There is a workaround I've found, by temporarily registering the store:
I know this is a niche situation, but I wonder if we could use some kind of duck-typing mechanism to check if a store implements a basic set of features, and allow it, even if it not a subclass of
rdflib.store.Store.All reactions