No need to check for attributeerror, codes is always there (it can be None though; the AttributeError in deepcopy is to handle the codes is None case).

Actually I think the default implementation of__copy__ will just work, i.e. removing the implementation of__copy__ and just havingdef copy(x): return copy.copy(x) would work? And likewise for__deepcopy__?

I agree thatcopy is redundant and copy.copy will work, it just didn't in previous case because it was incopy call what caused infinite recurrence. On the other hand__deepcopy__ implementation is kind of optimized, isn't it? I mean that it is not recurrently calling deepcopy on each of its members as default implementation should. However, custom__deepcopy__ implementation can backfire, when we add important members and it is more code to maintain.

To conclude, there are two implementations of__deepcopy__ in the sources, and three implementations of__copy__. The other__deepcopy__ implementation is for TransformNode class and sorts out descendants (without reading through the details I assume that it implements design requirements of the whole Transform system). The other__copy__ implementations are for TransformNode class again and Colormap class, where it seems legitimate (again meeting some external requirements).

I don't see any heavy lifting done in the Path copy functions, therefore I suggest removing__copy__,__deepcopy__, and optionally the members:Path.copy(),Path.deepcopy(), and their tests.

I'm not sure the optimization of deepcopy really matters here. So I agree with removing__copy__ and__deepcopy__;copy anddeepcopy on the other hand can stay as convenience methods (plus it avoids breaking backcompat gratuitiously, and there's precedent forcopy methods existing for convenience (e.g. onlist ornp.ndarray), and leaving the tests forcopy anddeepcopy also verify (somewhat) that using the default impls of__copy__ and__deepcopy__ is indeed semantically correct.

I have found out that__deepcopy__ implementation cannot be done by means ofcopy.deepcopy, the reason is even stated in the docstring:

The `Path` will not be readonly, even if the source `Path` is.

Some tests relies on this behavior, one example fromtest_artist.py :

@image_comparison(["clip_path_clipping"], remove_text=True)def test_clipping():    exterior = mpath.Path.unit_rectangle().deepcopy()    exterior.vertices *= 4    exterior.vertices -= 2...

The Path frommpath.Path.unit_rectangle() is readonly, but its deepcopy isn't.
I think that at this point I should just fix the shallow copy code, which throws exceptions and keep__deepcopy__ as it is, since it has some consequences.

Ah, sure enough.

no parentheses around the assert

Fixed inf765d04.