[Fredrik Lundh] > 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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4