RFI: Allow for defining external loads / dumps instead of Bunch. about tortilla HOT 4 CLOSED

I've changed a code example - I made several mistakes during editing yesterday. This should reflect the proposal better.

from tortilla.

I was working on something like this for Tortilla. At the moment I was only planning on supporting multiple parsers (aka loaders). The project is here.

The dumping part is pretty interesting what you're proposing. There are still some unknowns here:

• Are loaders and dumpers registered per endpoint? For example, the person endpoint expects persons, but the group endpoint expects groups.
• Should it be allowed to change to a different loader per request? If so, how?
• On which arguments is the loader applied? (params, headers, data)
• Can different arguments have different loaders?

The parsing is rather easy to implement. This could be configured with a format option per wrap and/or request, where format refers to an already registered parser. Bunchifying the parsed response would then be an optional argument defaulted to True.

I guess the type of the parsed response could be checked if it's a list, dict, or tuple and based on that it will be (optionally) bunchified. This prevents incorrectly bunchifying classes like Person from your example.

from tortilla.

Are loaders and dumpers registered per endpoint? For example, the person endpoint expects persons, > but the group endpoint expects groups.

Yes, that's true. But this is kind of the point exactly. This will rely on conversion done by the dumper.
loads/dumps expect callable ,not object . As long as this callable can be run on the object you pass, everything will work the way you expect - no matter what you pass ( let's say for a moment that post data parameter is data=<someobject>

Let's see what we can do:

# We can accept _any_ object  on which dict() can be called!
register = tortilla.wrap('https://people_register.com')
register.dumps=json.dumps
register.loads=json.loads

# Those will work properly, as long as dict(<obj>) returns dict
register.post(data=Person())
register.post(data=Group())

# Dict will be returned, with resulting json converted by json.loads
result_dict = register.get(Person(name='John'))

# Now bunch objects will be returned for ALL endpoints below register.
register.loads = lambda r: Bunch(json.loads(r))

# Ok, we have a subURL which accepts XML only
xml_register = register.xml_endpoint

# I'll gloss over on how those are implemented
xml.register.dumps = xml_from_dict

# Here we want to validate and deserialize from XML to native object, performing validation on the way
# So we'll use less generic loader.

xml_register.loads = person_from_xml

# Since Person implements dict-like interface we are still good to go
xml_register.post(Person(name='Mary'))
mary = xml_register.get(Person(name='Mary'))

assert isinstance(mary,Person) == True #true

## Now we need to download file. The name still has to be passed as json, but result will be a binary file.
## Let's try something different for a change - we can use loads parameter to pass a loader for a call
## This time we need to pass params to get in query part of URL. 
## Since our object implements dictionary interface - we don't need to define dumps for params - it could still work!!!! 

file_endpoint = register.files
binary_file = file_endpoint.get( params=FileParamsBuilder(name='list.txt'), dumps=None)

# The same example using post data - If our api requires post data:
binary_file = file_endpoint.post( data=FileParamsBuilder(name='list.txt'), dumps=None)

I'm not sure yet about the headers - there is a case of overwriting them, and there is a case of appending request-specific headers:

top_level_endpoint.headers = default_headers
endoint.headers.append(HeaderValidator(filename='file.txt))

I guess from the examples, for headers, and params (query part) what we need from an object is an ability to return dict. This will cover all the cases - and I think you don't need to implement anything for it to work ( you already call dict on headers, which should cover all dict-like objects. And request does this automatically too for params, so cases of headers and params are already covered - they just need a better documentation, so people can see what magical things they can do ( like validate parameters to get,post or use bunches instead (which makes code look prettier)

The only case left is data itself, and this can be covered by dumps ( both as an argument and as a property )

Makes sense?

from tortilla.

This has been added in v0.4.0.

from tortilla.