Inconsistent AttributeError on deepcopy about dendropy HOT 5 CLOSED

And of course I fix my own issue 10 minutes after sending the traceback... I was inadvertently modifying the DendroPy objects.
Regardless, in the event that an Edge object doesn't have an _annotations attribute, is halt and catch fire the desired behavior, or should this be caught and handled within DendroPy?

from dendropy.

Hi Steve,

Do I feel that non-compatible/unexpected client-code modification (presumably deletion) of a fundamental attribute, explicitly marked by standard Python convention of the leading underscore as "do not touch", of a member of the core data model as provided by DendroPy should be caught and handled by DendroPy?

No.

No more than we should check if "float()" or "str" has been deleted or otherwise modified/redefined in a breaking/incompatible/unexpected way by the user. Or, indeed, any of the other hundreds or thousands of elements, either as defined by DendroPy, or defined by the Python standard library or as a built-in. That would be thousands of thousands of lines of code just to check to see if that everything we wrote or Python provides has not been incorrectly modified by client code.

Python allows for great power if modification of the ecosystem. With great power comes great responsibility. We can only assume/hope that if client code modifies anything defined by DendroPy, or, indeed, Python, they do so with the full understanding and knowledge of what they are doing and they maintain compatibility with what DendroPy or Python user expects.

from dendropy.

I'm not hacking on protected attributes and then getting all confused because stuff is blowing up, but I suppose I deserved that. Touché. I'll be a little more clear about what I've done in the future.

Anyway, for the record, I did spend some more time digging and it looks to me like the override of deepcopy is the source of the issue, although I'm not sure why; I haven't been able to nail down a case that will consistently fail, and the only time exceptions seem to be raised is when I'm running through my unit tests. Given that my code isn't touching yours through protected attributes, I think that there might be some collision happening between dendropy and py.test. I was able to work around the problem, and I might be so far in the weeds that it doesn't matter, but I wanted to at least draw your attention to a possible issue in case it comes up again in the future.

Best,
-Steve

from dendropy.

Hi Steve,

The annotation infrastructure --- which allows for annotation sets to contain not only other annotation objects and annotation set object, but also other objects with their own annotation sets --- makes copying a very complicated operation. It is easily one of the more annoying parts of the data model to work with from this respect. Due to this, against all my coding preferences and instincts, the current native DendroPy data object copy logic is convoluted and fragile. It works, and it works well, AFAIK, but it is not a creature of beauty.

It is thus no surprise that this nexus (the annotations infrastructure + copying) was the point of failure in your code. I can only apologize for the complexity and fragility in this regard. Perhaps if you describe what you are trying to do with the override of the deepcopy, I might be able to provide some suggestions that might help. And maybe even look into working in logic in the native deepcopy that will prove robust to whatever you are doing at a higher level?

And, for the record, I truly appreciate you pointing it out problems with the library, whether or not the root cause is client code or library code. The bulk of my response above was in response to the suggestion that the library code should check to see if the core data structures had been changed/modified in a non-compatible way. This, I think, is both practically and conceptually unreasonable.

from dendropy.

Cool beans, and no hard feelings. I totally get your point.
As for trying to solve my deepcopy issues, I think it's best to just gently place another layer on the pile and tiptoe away (which I've done). I'm sure we'd both rather focus brain power on the bioinformatics ;)
-Steve

from dendropy.