Convert functions to accept RequestHandlers

[jaidevd]

See #304
This PR adds a decorator: gramex.handlers.functionhandler.add_handler which wraps any callable to:

1. get it's args and kwargs from handler.path_args and handler.request.body
2. return a JSON object
3. enforce any type annotations found in the callable

ToDo:

• Not exhaustively tested for POST / DELETE

[jaidevd]

handler.get_arg does this.

[jaidevd]

• Test all HTTP methods.
• Test all native types including None.
• Test what happens with default named arguments.
• ?x=1&x=2&x=3 should be doable. Perform the typecasting from the hints.

[pratapvardhan]

Perhaps {k: v if len(v) > 1 else v[0] for k, v in handler.args.items()} to handle ?x=1&x=2&y=3?

[jaidevd]

@sanand0 This ^ works, obviously. handler.get_arg('x') only gets the last value. Is that intended or is it a bug? Sounds to me a bit like what's at the heart of #312

[pratapvardhan]

Thoughts on using pydantic? See this example https://pydantic-docs.helpmanual.io/usage/validation_decorator/

[jaidevd]

@pratapvardhan this is great... I can offload all the typechecking / casting off to pydantic.validate_arguments.
Type validation should be on by default, and in that case, pydantic should do it. But users should also be able to turn it off if required, like:

@add_handler(validate=False)
def slow_sum(*numbers: float, delay: int):
   s = 0
   for i in numbers:
       time.sleep(delay)
       s += 0
       yield s

This ^ snippet won't complain when numbers is not floats, say.

@sanand0 Thoughts?

[sanand0]

No inputs -- and we can defer this.

[jaidevd]

@sanand0 items from the last review are done. Some notes on usage are in the docstring for add_handler. Please take a look.

[sanand0]

• Move add_handler as gramex.transforms.handler
• Fix typos in docstring
  • greet.,py -> greet.py
  • funtion -> function
  • andd -> and
  • Please check for others
• Change usage to:

pattern: /$YAMLURL/greet
handler: Function
kwargs:
    function: greet.birthday

• This test case should

def total_list(items: List[float], start: float) -> float:
    return sum(items) + start

• In POST and PUT requests, URL parameters and path arguments should be used. Add test cases

[sanand0]

These scenarios don't yet work.

url:
  power:
    pattern: /power
    handler: FunctionHandler
    kwargs:
      function: alpha.power
      kwargs:
        x: 3

  message:
    pattern: /message
    handler: FunctionHandler
    kwargs:
      function: alpha.messages

@handler
def power(x: int, y:float) -> float:
    return y ** x


@handler
def messages(s: list):
    for msg in s:
        yield msg

[jaidevd]

@sanand0 Added these two cases, and tests for them.

[sanand0]

I made these changes:

• Make all handler names, URL patterns and function names identical
• Move @handler methods from test_function.py to functionutils.py. This is to allow manual testing. Specifically, if cd tests and run gramex to visit localhost:9999, Gramex can't import tests.test_function because it has a line from . import TestGramex.
• Split tests into a test_functionhandler.TestWrapper class so we can run them independently
• If ?x=1&x=2 are passed to func(x: int), then the last parameter is used, not the first
• POST body is processed as JSON only if Content-Type: application/json. This is consistent with FormHandler. It also retains the URL query parameters apart from the body
• Modify FunctionHandler to return list, int, float, etc.
• If we call /func/total/10/20?items=30&items=40 it will add 10+20+30+40=100. This required a rewrite of the code base.

[sanand0]

Note: Checks failed because Travis couldn't access the Microsoft R repository. Even master fails despite the same commit passing earlier.

This is because requests.get('https://cran.microsoft.com/src/contrib/PACKAGES') fails due to an SSL issue.

So I've gone ahead and merged.