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 josh.r
Recipients anton.barkovsky, gregory.p.smith, htgoebel, josh.r, methane, pitrou, r.david.murray, rhettinger, serhiy.storchaka
Date 2021-01-13.04:52:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1610513546.85.0.273336957249.issue15373@roundup.psfhosted.org>
In-reply-to
Content
Would we remove the functionality of os.environ.copy()? It seems very odd for types to have a .copy() method that works, while not supporting copy.copy, especially when there is zero documentation, on the web or the docstring, to even hint at the difference.

I'm strongly in favor of silently doing the right thing and behaving the same way the .copy() method already behaves; if you want a "copy" of os.environ that still modifies the environment, that's just aliasing it (envalias = os.environ), not copying at all. If you're trying to make a shallow copy, not an alias, you're trying to separate it from the parent, which every other dict-like thing does (assuming immutable values), where os.environ is a very weird exception (for copy.copy, but not the .copy() method).

Can someone give an example where you'd want copy.copy to produce a "shallow copy" that acts like an alias, not an actual independent copy?
History
Date User Action Args
2021-01-13 04:52:26josh.rsetrecipients: + josh.r, rhettinger, gregory.p.smith, htgoebel, pitrou, r.david.murray, methane, serhiy.storchaka, anton.barkovsky
2021-01-13 04:52:26josh.rsetmessageid: <1610513546.85.0.273336957249.issue15373@roundup.psfhosted.org>
2021-01-13 04:52:26josh.rlinkissue15373 messages
2021-01-13 04:52:25josh.rcreate