Allow custom store implementations to not inherit from rdflib.store.Store #1538
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 |
Beta Was this translation helpful? Give feedback.
-
I don’t think the just-in-time registration’s a workaround: that’s the expected solution, as per other parsers and serialisers’ registration. |
Beta Was this translation helpful? Give feedback.
-
Opening this as a discussion topic.
Currently, when instantiating a
Graph
instance with a pass-instore
instance, thestore
parameter 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
MySpecialStore
does not inherit fromrdflib.store.Store
so 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
.Beta Was this translation helpful? Give feedback.
All reactions