Join the Kedro community

Updated 4 weeks ago

Kedro's approach to public and internal APIs

How does the Kedro dev team think about delineating what components belong to the public API vs being internal-use only?

I see single leading underscores _<foo> are used, which I assume means they belong to the private API.

'Sometimes' I see <i><code>__all__</code></i> is used. Are things in that list safe to assume as part of the public API?

If a variable (function/method/class/etc) does not have a leading underscore, and is not in a __<i><code>all_</code></i>_ , does that mean it is safe to assume it is also part of the public API?

D
N
G
4 comments

TBH I don't think Kedro is that consistent in terms of how it defines a public API. At the same time, the team is very conservative around what constitutes a breaking change (almost any breaking change to a non-underscored field or method is considered grounds for a minor version bump).

Quick answer: I think yes.

Is there an example where it's not in _<i><code>all</code></i>_ but it does not have a leading _?

I think sometimes it's in _<i><code>all_</code></i> because we want to surface the API a little bit instead of from a.b.c.d.e.f import x,y,z .

In pricinple anything does not have a _ is consider "public" that we try not to break it during minor release.

Thanks!

Is there an example where it's not in _<i><code>all</code></i>_ but it does not have a leading _?

I have not checked. Just wanted to know what I can assume about what is stable for users.

Add a reply
Sign up and join the conversation on Slack