which leads to a followup question: the current approach seems to be to hack the copy.py file for each and every type. imo, that's rather unpythonic, and also introduces lots of unnecessary module dependencies.
time to add a __clone__ slot?
Note that classes can supply custom cloners via defining __copy__ and __deepcopy__ methods, without changing copy.py.
A __clone__ slot for *types* would need to address the shallow vs deep question too, along with the other __getinitargs__, __getstate__, __setstate__ gimmicks. How many slots does that add up to? I leave it to the PEP author to count them <wink>.
The copy.py protocols kinda grew up with pickle.py's, and together still have the flavor (to my tongue) of a prototype caught late in midstream. That is, it feels like they're not quite finished yet.
or could someone who knows what he's doing here address this comment in copy.py:
# XXX need to support copy_reg here too...
copy_reg is one of the pickle.py facilities that copy.py "should use" too; it's a registration database that tells pickle what to do about objects of types pickle doesn't understand directly (so *could* also be directly relevant to cloning objects of types copy.py doesn't understand directly -- depending).