Forgot about register_pickle_by_value/unregister_pickle_by_value whic…

…h is also part of the public API

README.md

@@ -84,12 +84,13 @@ that pickles such constructs **by value**.
 Another case where the importability assumption is expected to break is when
 developing a module in a distributed execution environment: the worker
 processes may not have access to the said module, for example if they live on a
-different machine than the process in which the module is being developed.
-By itself, `cloudpickle` cannot detect such "locally importable" modules and
-switch to serialization by value; instead, it relies on its default mode,
-which is serialization by reference. However, since `cloudpickle 2.0.0`, one
-can explicitly specify modules for which serialization by value should be used,
-using the `register_pickle_by_value(module)`/`/unregister_pickle(module)` API:
+different machine than the process in which the module is being developed. By
+itself, `cloudpickle` cannot detect such "locally importable" modules and
+switch to serialization by value; instead, it relies on its default mode, which
+is serialization by reference. However, since `cloudpickle 2.0.0`, one can
+explicitly specify modules for which serialization by value should be used,
+using the
+`register_pickle_by_value(module)`/`/unregister_pickle_by_value(module)` API:
 
 ```python
 >>> import cloudpickle

cloudpickle/__init__.py

@@ -1,7 +1,15 @@
 from cloudpickle.cloudpickle import *  # noqa
 
-__version__ = '3.0.0.dev0'
+__version__ = "3.0.0.dev0"
 
-__all__ = [ # noqa
-    "__version__", "Pickler", "CloudPickler", "dumps", "loads", "dump", "load"
+__all__ = [  # noqa
+    "__version__",
+    "Pickler",
+    "CloudPickler",
+    "dumps",
+    "loads",
+    "dump",
+    "load",
+    "register_pickle_by_value",
+    "unregister_pickle_by_value",
 ]