Closed sanand0 closed 2 years ago
Well, anything directly related to Part
is really an implementation detail, and I need to reserve the right to refactor the implementation, so I'd say no, I'd prefer not to maintain support for that, given I've come to consider it an early design misstep.
You could however monkey-patch Part with something like:
def related_parts(self):
return {
rId: rel.target_part
for rId, rel in self._rels.items()
}
if pptx.__version__ > whatever_version:
pptx.opc.package.Part.related_parts = related_parts
I'm a little rusty on the details of monkey-patching, but maybe this gives the gist. In any case, if you can get that to work at least you don't need to dig through your code for all the calls.
One of the wages of extending based on internals I'm afraid, something I face myself from time-to-time.
Perfectly reasonable. Thanks @scanny -- please feel free to close the issue. I'll work with this.
shape.part.related_parts
is mentioned in a few places online.From 0.6.20 onwards, the
shape.part.related_parts
mapping seems to be missing. Instead, we have theshape.part.relatedpart()
function.Since there's existing code that's based on some of the documentation above, would it be possible to retain the
.related_parts[]
interface? Or is there a strong reason to move away from it?