Data structures

[Jeadie]

Hi Ramnes,

I love the work you've done so far on the Notion SDK for python. I had a couple ideas to implement in the SDK if you thought they'd be of value:

• Simple data classes on top of the various API objects for Typing and abstraction.
• Implementing natural pythonic pagination and iteration

I'll fork the repo and start work on these. Let me know what you think of these and I can make a PR when I'm done.

Cheers,
Jeadie

[ramnes]

Yeah I really want this too, but I'm torn between keeping the library API as close as possible to the javascript SDK, or making it higher level, i.e. in the lines of notion-py. I was thinking that maybe we could keep this library quite bare and write another one based on it, with much more batteries included, just like botocore and boto3 for example. What do you think?

[Jeadie]

I can't see that hurting, especially to keep more minimal python integrations, for example, less bloated. I'll start a new repo tomorrow (GMT+10) and use your library as the underlying connection.

[blue-hope]

btw I agree with @ramnes that we should develop further, not stay in Js SDK. The api level we support should follow the official api announcement, but we will be able to support additional functions such as watching record in notion-py. The priority is to follow our library as much as possible, similar to js :)

[ramnes]

Yeah I think we all want a higher level experience. The only questions are what features, what API, and how to structure the code.

After more thoughts, I'm wondering if the double-package scheme is optimal, and if we shouldn't rather have everything in here with different Python namespaces, so that the switch to a code generator would be easier when they'll release an OpenAPI specification file. That would also make more people work on a single codebase, which is a good way to increase the overall bus factor.

Maybe we could put all the current code in a notion_client.base module (or "sdk", or "core"), which would always stay the equivalent of the JS SDK, and write some nice wrappers around it in the first-level package, just like I've made for sftpgo-client.

What do you guys think?

[Jeadie]

I think at the very least we should move them to separate modules. In so far as my WIP PR, I'll continue to work on it as if it was to be integrated with this repo. I'll move it to a module called "lib". This should allow development to continue on it whilst we make a decision for separability going forward.

I'm probably more in favor of a single-repo, dual-module structure. I think in terms of the lifecycle and maintenance of the code itself one is better than two (e.g. less configs, setups, .Github/ ). I suspect most of the end users would prefer to use library calls instead of api calls.

The counter to this is correctly, probably just bloat. One could imagine the library code being rather large, so in use cases where people want to make a simple or single Notion call, the overhead of a large package with both client and lib is excessive.

But as I said, I'll continue the lib work in a separate module as that allows us time to consider the options and makes both solutions easy to implement.

[odeckmyn]

Did you guys finally decide to make a new lib on top of notion-sdk-py or modify notion-sdk-py ?

[aahnik]

as the name is "sdk", it should be a complete toolkit. The current project is the "core" or "raw", we need high-level features on top of this. I don't like the policy of being close to the js lib.

Telethon has a core, that does raw RPC methods, and a client library on top of it, that provides a friendly pythonic interface.

I don't have any prior experience, writing such API wrappers, but I am in favor of a single repo. I am very curious to know what @ramnes thinks.

[ramnes]

Yeah I did write a comment in favor of a single repository, and it looks like we all agree, so let's go for it. :)

[Jeadie]

Sounds good. I'll have a PR up before the end of the weekend 23/5

[odeckmyn]

Guys, how can we use this new work ? Have to wait the release, I presume ? Thanks !

[jheddings]

As another option, I've started a "higher level" module that builds on the SDK. That would allow the core to stay as close to the official SDK as possible and provide another level of abstraction for those who want it.

If you are interested, check out notional.

[ramnes]

Let's put this on hold and use notional as a pilot. :)