[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

Vinay Sajip added the comment: Closing as per Serhiy's advice - assume that's OK. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

Serhiy Storchaka added the comment: So that I think we can close this issue, since this is not a bug, but an intentional behavior. copy.copy() also consider functions and classes as atomic, although they are not immutable, and there are use cases for making a modified copy. --

[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

sebix added the comment: > I suggest as a workaround that a context manager approach could be used to > save and restore part of the logging configuration around various operations > (at least levels and handlers), as outlined here: >

[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

Vinay Sajip added the comment: Loggers are singletons, so the pickling operation just pickles the name. Unpickling just leads to getting the pickled name and calling getLogger(name), which will return the same object that was pickled (I'd forgotten about issue30520). I suggest as a

[issue34999] copy.copy and deepcopy do return same logger objects in 3.7

sebix added the comment: Oh, that's something different than I initially thought. Using copy.deepcopy gives the same result as with copy.copy. -- title: Different behavior of copied loggers in 3.7 -> copy.copy and deepcopy do return same logger objects in 3.7 type: -> behavior