Compatibility with Pyodide

[fcollonval]

Hey thanks a lot for this amazing tool.

I was trying it in the in-browser interpreter Pyodide and got the following error:

As pickle works in that interpreter, I was wondering if you could be interested into making this package compatible with the in-browser interpreter?

[mmckerns]

Sure.

Apparently, the environment doesn't like:

>>> open(os.devnull, 'r+b', buffering=-1)
Traceback (most recent call last):
  File "<console>", line 1, in <module>
io.UnsupportedOperation: File or stream is not seekable.

which dill assumes can be open as a BufferedRandomType.
The easiest thing to do, is if this operation is not possible, then try and if fail don't register the type... or even better would be if there's some indicator you are working in that environment, then don't register the BufferedRandomType -- unless there's some other way to create it with pyodide.

[fcollonval]

Thanks for the answer

The easiest thing to do, is if this operation is not possible, then try and if fail don't register the type...

I was thinking about something like that

or even better would be if there's some indicator you are working in that environment, then don't register the BufferedRandomType

There is the sys.platform == 'emscripten' in that case. It seems to have been adopted by the experimental CPython build too: https://github.com/python/cpython/blob/main/Tools/wasm/README.md#python-code

unless there's some other way to create it with pyodide.

Not that I know of - but this is an highly changing technology

[mmckerns]

I tried testing this by using micropip to install from git+https://github.com/uqfoundation/dill.git@master, but it seems that micropip didn't like the URL. Not sure if it's possible to install from git with micropip. Do you know if it's possible? I'm going to cut a new release, so this is potentially a moot question, and we will see if it worked post-release.

[fcollonval]

Thanks a lot @mmckerns for fixing it - I see the latest version is importable in pyodide

[mmckerns]

Great. If you can run the test suite, let me know if something breaks. I believe one test has a BufferedRandomType so that should fail -- I expect that I will need to guard that entry as well. That particular test has a plethora of different types that it will attempt. If not, I'll try to remember to check it.

[mmckerns]

I did the additional cleanup of the BufferedRandomType, so that it's skipped everywhere for the target platform. It shouldn't come into play unless people run the test (or import) of dill.objects for the "objects that fail" group.