Python client

[matryer]

We are working on a Python client for Oto.

Can you help?

[sethcenterbar]

👋 I've got some time this weekend. Are there any more specific requirements or goals for this client?

[matryer]

Hey Seth, that'd be great.

We're trying to add type checks to the Python request objects. And maybe return some typed objects that are easy to extract the data from?

[matryer]

Here's what we have so far: https://github.com/pacedotdev/oto/blob/master/otohttp/templates/client.py.plush

It works :) But we want to improve the dev experience but adding some type help, and some better docs.

• Typing in Python https://docs.python.org/3/library/typing.html
• Better docs in Python https://www.python.org/dev/peps/pep-0257/

[sethcenterbar]

Awesome. Going to get started in just a bit and hopefully have something today.

[matryer]

Great - maybe it's worth building a little example Python script that talks to the example service in /example?

[sethcenterbar]

I've added python generation to /example.

Just want to make sure I'm on the right track when it comes to the 'Typing in Python' objective. I'm thinking the struct generation happening in the following code..

# server.go.plush
<%= for (object) in def.Objects { %>
<%= format_comment_text(object.Comment) %>type <%= object.Name %> struct {
	<%= for (field) in object.Fields { %><%= format_comment_text(field.Comment) %><%= field.Name %> <%= if (field.Type.Multiple == true) { %>[]<% } %><%= field.Type.TypeName %> `json:"<%= field.NameLowerCamel %><%= if (field.OmitEmpty) { %>,omitempty<% } %>"`
<% } %>

..should be added to the python client plush as classes instead of structs, with python type hints instead of explicit go types.

[matryer]

Yeah I think so.

The trouble I have is that I don’t know what the Python code is supposed to look like :)

I guess the goal would be so that a) people know what to put in without necessarily consulting the docs, and b) the runtime could even throw an errors if there are unwanted fields. Little touches like this make consuming the SDK easier, which is the ultimate goal.

Mat

On 21 Nov 2020, at 17:27, Seth Centerbar [email protected] wrote:

I've added python generation to /example.

Just want to make sure I'm on the right track when it comes to the 'Typing in Python' objective. I'm thinking the struct generation happening in the following code..

server.go.plush

<%= for (object) in def.Objects { %> <%= format_comment_text(object.Comment) %>type <%= object.Name %> struct { <%= for (field) in object.Fields { %><%= format_comment_text(field.Comment) %><%= field.Name %> <%= if (field.Type.Multiple == true) { %>[]<% } %><%= field.Type.TypeName %> json:"<%= field.NameLowerCamel %><%= if (field.OmitEmpty) { %>,omitempty<% } %>" <% } %> ..should be added to the python client plush as classes instead of structs, with python type hints instead of explicit go types.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/pacedotdev/oto/issues/26#issuecomment-731608833, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAY2GZQT7YP2QBAVKHBCPLSQ7Z7JANCNFSM4T3D2YVQ.

[sethcenterbar]

Yeah I think so. The trouble I have is that I don’t know what the Python code is supposed to look like :) I guess the goal would be so that a) people know what to put in without necessarily consulting the docs, and b) the runtime could even throw an errors if there are unwanted fields. Little touches like this make consuming the SDK easier, which is the ultimate goal. Mat …

Unfortunately, python is still going to rely pretty heavily on docstrings to be discoverable, even with type hints.

There are quite a few standards on docstrings in python, but this guide is pretty clear cut. I'm going to start implementing it because I think it's the most readable, but I could also see some pythonistas looking for sphinx style documentation. I guess that could just be another template.