-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Why
When we write code using python objects, then dispatch some of these to a webservice (py2http), and then get python wrappers of the latter (http2py), we'd like to be able to use the original code as is (as much as possible).
But when we do the py2http2py, python objects are normalized. Amongst other things, we "flatten" nested structures. We'd like to be able to "restructure" these flat functions.
Examples
Instance methods
When we make an instance of a class and use it's methods:
instance = Class(**init_kwargs)
a = instance.method(**method_kwargs)This sequence gets flattened to a single function that can be used as such
a = func(**(init_kwargs + method_kwargs))
It's functional (pun), but we'd like to be able to have the choice of creating a WsClass that uses func to offer the same interface:
instance = WsClass(**init_kwargs)
a = instance.method(**method_kwargs)
Stores (Mappings)
The dol ecosystem (py2store, etc.) allows us to write code where CRUD operations have a normalized interface. We can read data doing v = store[k], write doing store[k] = v, delete doing del store[k] etc. with storage details abstracted away.
So being able to create web services for stores (i.e. MutableMapping interfaces) and visa-versa being able to get the same store interface wrapped over these web-services can go a long way.
How
Using i2.wrapper, write ingress and egress function factories specialized for the restructuring purpose.