erewok / servant-py Goto Github PK

We have a capture in one of our test API endpoints where the variable is named id. This is created as a function parameter and passed into the client function.

Ideally, we wouldn't overload any Python keywords, such as id, because it's gross and poor form.

Possibly check for membership in a list of keywords and rename if so.

requests is great for synchronous http

treq is great for asynchronous http

With the new Async stuff in Python, we should be able to emit client code in servant-py that will utilize httpx and asyncio. We can add it here as a different generator.

It'll build a dict like this:

test :: [Text] -> Text
test = ["one", "two", "three"]

let result = toPyDict test
result
\"{\"one\":one\"two\":two\"three\":three\"}

We forgot to build a complete structure out of it. Probably pass an offset parameter to fix this so it nicely indents members of the resulting dict.

So, I have been thinking about this library and I think I'd like to make the output functions a little more usable. I had the following ideas:

1. Build Class definitions for URLs where the route is totally common but there are different methods, something like this:

class SomeRoute:
    def __init__(self):
      self.url = "some/url/{param1}/etc"
      pass
    def get(self, param1):
      return requests.get(self.url.format(param1=param1))
   def post(self, param1, payload):
      etc.

2. Instead of (or in addition to) the above, we could also separate functions into modules so that you can do something like dotted function call:

import some_url_client

some_url_client.get()

The default way of naming functions creates really long functions, so we need something consistent that also creates an API that's not ultimately painful to use.

I'll experiment and try to see what'll work best.

Docstring now doesn't contain a returns: section, which would make it a little more official.

Ideally, we'd include more information about the types of things that go into the functions as arguments, including the data payload, etc. That may involve more knowledge about Python than this library currently pretends to.

In addition, we should be able to include some information in the returns section about the kind of object likely to get returned.

They are sorely needed.

It should be fun to do.

once the tests are great.

to track releases and such

Part of the test suite which is commented out fails now if tweaked slightly to fix a type error:

    it "should build urls properly with / separator" $ do
      let pyUrl = makePyUrl customOptions (UnTypedPythonRequest req) " "
      pyUrl `shouldBe` "\"urlForRequesting:9000/login-with-path-var-and-header/{id}/{Name}/{hungrig}\""
                       <> withFormattedCaptures " " pathParts

Failures:

  test/Servant/PY/InternalSpec.hs:131:7: 
  1) Servant.PY.Internal.Servant.PY.Internal.Internal, functions that operate on Req objects, should build urls properly with / separator
       expected: "\"urlForRequesting:9000/login-with-path-var-and-header/{id}/{Name}/{hungrig}\".format(\n id=parse.quote(str(id)),\n Name=parse.quote(str(Name)),\n hungrig=parse.quote(str(hungrig)))"
        but got: "\"urlForRequesting:9000/login-with-path-var-and-header/{id}/{Name}/{hungrig}\".format(\n id=parse.quote(str(id)),\n Name=parse.quote(str(Name)),\n hungrig=parse.quote(str(hungrig)))\""

This library has fallen pretty far behind Servant versions, so we should build against a more recent version and also fix our dependencies to be better defined.

This library contains a confusingly named withTypes Python generator options, but we're not using Python3 type annotations, when it seems like we should be.

Add a new style of generating Python output using Python3 type annotations.

Default is to call it on all captured args:

https://github.com/pellagic-puffbomb/servant-py/blob/master/src/Servant/PY/Internal.hs#L260

Figure out how not to do that for integers or make sure that are all captures passed are strings.