Make GLPickle more extensible.

[srikris]

Summary of changes

• Made GLPickle more extensible
• Used the extensibility mechanism to implement things for Model, SGraph,
  SFrame, and SArray.
• Added some additional tests for the same.

Details

Previously, GLPickle could not be extended without making changes directly to
it. Now, we added a mechanism to extend it by implementing 2 simple
methods:

1. gl_pickle_save: Save your object to a filename (not handle) given to you.
2. gl_pickle_load: Load your object from a filename (not handle) given to you.

As an example, here is a simple class that was extended to be pickled via
GLPickle.

class SampleClass(object):
  def __init__(self, member):
     self.member = member

  def __gl_pickle_save__(self, filename):
      with open(filename, 'w') as f:
          f.write(self.member)

  @staticmethod
  def __gl_pickle_load__(filename):
      with open(filename, 'r') as f:
          member = f.read().split()
      return SampleClass(member)

[TobyRoseman]

For PY3 support, you'll also need to always use relative imports:

from ._gl_pickle import GLPickler
from ._gl_pickle import GLUnpickler

Notice the periods.

[ylow]

@srikris Can you do a merge with master again?

[srikris]

@ylow Done.

[ylow]

• Lets not bump the version number. This can be avoided simply by type checking of the type_tag.
• Also, the mechanism of serializing the load method will cause problems. This means that if any point, there is a bug in the load method, any previously saved object will no longer be loadable since it is depending on the implementation of the load method which is fully serialized into the pickle.
• This may also make Python 2 saved objects not loadable in Python 3 and vice versa.

Instead you should just save the module import path to the load method and find it on deserialization.

[ylow]

@srikris progress on this?

[rbkreisberg]

@srikris @ylow is this going into the 1.9 release?

[srikris]

This will go in right after 1.9. I plan to fix it soon.