Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discussion Topic: Python 3 Bindings #52

Open
eboto opened this issue Mar 22, 2017 · 1 comment
Open

Discussion Topic: Python 3 Bindings #52

eboto opened this issue Mar 22, 2017 · 1 comment

Comments

@eboto
Copy link
Contributor

eboto commented Mar 22, 2017

Hey y'all,

Having Python bindings for Courier has become increasingly important for us at Instrumental as we scale up our dependence on the language for ML and other flows. As such, I've posted a work-in-progress PR that generates python3 bindings from courier templates. It's at the point where it works in most cases and can be used to idiomatically create, serialize, deserialize, and validate the types in your courier templates. It's not at the point where it's worth reviewing the code.

In the README you will see the details of what is yet-to-be-implemented and what I intend to leave for later. At this point I will be interested in a couple high-level questions:

  • Will a Python3 generator be a good addition to main-line courier?
  • General input on the API and idioms of the generated code (e.g. courier.dumps(obj))
  • Among the remaining features called out under Features missing in action in the PR, some rough sense of priority. Or if they are necessary at all for merge into main-line.

I will be continuing to work on it here and there for the next few weeks before it will be ready for merge. Particularly we will be dogfooding it internally to hammer out the rough points of the generated API.

See the python test-cases for examples of how the API works as-written. The basic gist is:

# Assume we have generated python bindings into the `generated` package
import generated.courier as courier
from generated.org.example.MagicEightBall import MagicEightBall
from generated.org.example.MagicEightBallAnswer import MagicEightBallAnswer

json = """{"question": "Will I ever love again?", "answer": "IT_IS_CERTAIN"}"""
ball = courier.parse(MagicEightBall, json) # raises courier.ValidationError if doesn't match schema

assert(courier.serialize(ball) == json) # Passes
ball.message = 'Am I human?'
new_ball = MagicEightBall(message='Am I human?', answer=MagicEightBallAnswer.IT_IS_CERTAIN)

assert(ball == new_ball) # Passes
@eboto eboto mentioned this issue Mar 22, 2017
21 tasks
@amory-coursera
Copy link
Contributor

Thanks for all the work on this @eboto . Definitely a candidate for the main-line, in my view. Schema languages are far more powerful if they support communication between separate application domains, and Coursera uses python as a utility and tool language, so we would benefit directly.

Of your MIA features, I'd say that optional fields, defaults values are highest priority. The rest are optional in my view, although nice to have.

Let us know when the code ready for review and we'll pitch in to help it land.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants