Fix #94: allow pickling Logger objects

[pitrou]

No description provided.

[codecov-io]

Codecov Report

Merging #96 into master will increase coverage by 0.3%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master      #96     +/-   ##
=========================================
+ Coverage   79.88%   80.18%   +0.3%     
=========================================
  Files           2        2             
  Lines         522      530      +8     
  Branches      109      110      +1     
=========================================
+ Hits          417      425      +8     
  Misses         75       75             
  Partials       30       30

Impacted Files	Coverage Δ
cloudpickle/cloudpickle.py	80.07% <100%> (+0.3%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 91eae7b...26f91d7. Read the comment docs.

[llllllllll]

You could use textwrap.dedent here to fix the indentation instead of the if.

[pitrou]

textwrap.dedent is a bit more annoying to use (you have to make sure the first line has the same indent as the other ones, which this idiom doesn't require).

[pitrou]

Interesting: the dispatch dict doesn't support old-style classes, which is why the test fails on 2.6.

[mrocklin]

So, my experience when I run into the issue of cloudpickle not being able to serialize a logger is that cloudpickle is actually trying to serialize everything. The solution in these cases is almost always to find out why. It's probably still correct for cloudpickle to learn how to serialize logger objects, but we may want to ask ourselves why this is occurring.

[pitrou]

It's probably still correct for cloudpickle to learn how to serialize logger objects, but we may want to ask ourselves why this is occurring.

It's occurring simply because Logger objects don't have a custom __reduce__ method, so pickle tries to reconstruct them structurally (which entails also reconstructing the handlers attached to them, which is a slippery slope as often those have I/O objects attached to them).

[pitrou]

Note reconstructing by calling getLogger(name) is really the right thing to do, as loggers really are lazily-instantiated named singletons. Their configuration needn't be serialized and may well be different in different processes or runs.

[pitrou]

Are there any other comments before this get merged?