This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author p-ganssle
Recipients asvetlov, eli.bendersky, gphemsley, mdk, p-ganssle, r.david.murray, scoder, thatiparthy
Date 2017-12-28.23:01:32
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1514502092.76.0.213398074469.issue32424@psf.upfronthosting.co.za>
In-reply-to
Content
> There is no "fork" involved in other projects using it, from our point of view.

I did not mean "fork" in some judgmental sense, I'm mostly just familiar with pypy, but I was under the impression that other projects were *literally* forking the standard library as a practical matter. I get the impression that other interpreters maintain a patched interpreter often for the purposes of adding fixes like the one pointed out in msg309131 which bring the behavior of the Python implementation of the standard library into line with the C implementations, since the C version is the de facto standard (since most code is written and tested only for CPython).

I'd be fine with adding a C alias for `copy`, though as a purely practical matter, I strongly suspect that dropping `copy` from the pure Python implementation would not be a huge deal, but if that breaks the contract it breaks the contract.
History
Date User Action Args
2017-12-28 23:01:32p-gansslesetrecipients: + p-ganssle, scoder, r.david.murray, eli.bendersky, asvetlov, thatiparthy, mdk, gphemsley
2017-12-28 23:01:32p-gansslesetmessageid: <1514502092.76.0.213398074469.issue32424@psf.upfronthosting.co.za>
2017-12-28 23:01:32p-gansslelinkissue32424 messages
2017-12-28 23:01:32p-gansslecreate