Alias CloudPickler in the cloudpickle namespace as Pickler

[dbczumar]

Currently, the Pickler class in the cloudpickle namespace refers to pickle.Pickler. Certain libraries, such as PyTorch, leverage the Pickler class of a specified pickling module to serialize objects (see https://github.com/pytorch/pytorch/blob/fc5b79cd1c6020c20640128e43bac43fd636121e/torch/serialization.py#L290). When these libraries attempt reference the cloudpickle.Pickler, they obtain the pickle.Pickler class instead of cloudpickle.CloudPickler.

Working under the assumption that users referring to cloudpickle.Pickler desire/expect a reference to cloudpickle.CloudPickler, this PR aliases cloudpickle.CloudPickler as cloudpickle.Pickler and imports pickle.Pickler as _Pickler to avoid a naming conflict.

[codecov-io]

Codecov Report

Merging #235 into master will increase coverage by 0.02%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #235      +/-   ##
==========================================
+ Coverage   85.12%   85.15%   +0.02%     
==========================================
  Files           1        1              
  Lines         585      586       +1     
  Branches      117      117              
==========================================
+ Hits          498      499       +1     
  Misses         63       63              
  Partials       24       24

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

---

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 be70ffe...71897dd. Read the comment docs.

[dbczumar]

@ogrisel Can you take a look at this? Thanks!

[ogrisel]

I am fine with this. Please add a changelog entry targeting the 0.8.0 release.

Before merging I would like to have the opinion of other developers / downstream users of cloudpickle. Pseudo-random ping:

@rgbkrk @pitrou @HyukjinKwon @mrocklin ...

[mrocklin]

No objection from me.

…

On Thu, Jan 24, 2019 at 5:55 AM Olivier Grisel ***@***.***> wrote: I am fine with this. Please add a changelog entry targeting the 0.8.0 release. Before merging I would like to have the opinion of other developers / downstream users of cloudpickle. Pseudo-random ping: @rgbkrk <https://github.com/rgbkrk> @pitrou <https://github.com/pitrou> @HyukjinKwon <https://github.com/HyukjinKwon> @mrocklin <https://github.com/mrocklin> ... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#235 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszPAMa_VmZ7aWGPpS5fI5GGR4PbSmks5vGbs3gaJpZM4aP1TI> .

[pitrou]

I don't think we should change the public API of the cloudpickle module; this will become confusing, especially as the different behaviour between two cloudpickle versions might not be immediately obvious.

OTOH you could object that cloudpickle has always been experimental and subject to change without notice.

Certain libraries, such as PyTorch, leverage the Pickler class of a specified pickling module to serialize objects

Well PyTorch should perhaps be more flexible. I don't understand the concept of making the module name configurable, rather than the actual serialization functions (or classes).

[ogrisel]

+1 for using a FutureWarning when instantiating cloudpickle.Pickler now and schedule to do the switch in cloudpickle 1.0 then.

[rgbkrk]

If we go with this, we better leave a comment as to why we're using _Pickler here as some future contributor & maintainer may not know the context and end up breaking this use case.

[ogrisel]

Very good point.

[rgbkrk]

@dbczumar -- could you add the context around this PR to the import(s) to help our future selves?

[ogrisel]

This was done in #366.

Furthermore #517 will re-alias the other way around: cloudpickle.CloudPickler will become an alias to cloudpickle.Pickler which will become the main class.