Ah yeah I had a good discussion today about unsuccessful (and abandoned) attempts to try to sandbox python in Python 2. You are probably right that it is not pythonic and likely we will never be able to fully "forbid" something. Indeed "forbidding" might be a bit too strong. But warnings and explicit "This MAY not work in future versions" might be a better approach.
J. On Mon, Feb 24, 2020 at 3:40 PM James Meickle <[email protected]> wrote: > > I think that trying to *forbid* this is really not Pythonic. A more > appropriate way would be to have import paths ("from airflow.internals"), > docstrings, and warnings (via the silenceable warnings module) indicating > which APIs are "internal" (i.e., subject to change even in patch versions). > That is, let's try to build warning signs rather than walls. > > On Mon, Feb 24, 2020 at 9:27 AM Jarek Potiuk <[email protected]> > wrote: > > > I would like to open another discussion :) .. Following recent discussions > > about the "DAG" being an important internal API of Airflow but also > > following this post: > > > > https://medium.com/maisonsdumonde/road-to-add-form-for-airflows-dag-1dcf2e7583ef > > > > I think we should consider marking certain internal parts of Airflow > > classes as a stable/formal API for DAG writers. I think we can do it fairly > > easily with AST parsing while importing the DAGs and first deprecating in > > 2.0 and then forbidding in 2.1 using internal objects/methods APIs that we > > do not consider as "stable". I'd go for "allowed list" and forbidding > > everything else. > > > > I have no list of the "proposed" stable APIs yet, but I wanted to check if > > others think that this is a good idea as well. > > > > WDYT? > > > > J. > > > > -- > > > > Jarek Potiuk > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > M: +48 660 796 129 <+48660796129> > > [image: Polidea] <https://www.polidea.com/> > > -- Jarek Potiuk Polidea | Principal Software Engineer M: +48 660 796 129
