Another thing I was thinking that to move out those methods altogether to a separate class or module and so execution of a dag or those methods is done from different place and then Dag class will be very slim and will only be used to describe definition of a Dag.
On Mon, 4 Oct 2021, 08:33 Khalid Mammadov, <[email protected]> wrote: > I was thinking to follow as you mentioned the very few Pythonic notations > for private methods i.e. just add an underscore in front of it this example > to signal a user/dev this is private and an internal implementation and not > part of public API or otherwise it's. > > On Sun, 3 Oct 2021, 23:50 Jarek Potiuk, <[email protected]> wrote: > >> Well. Not sure what else you'd expect, I wonder ? >> >> This is for sure unexpected and not reasonable use of it. There are best >> practices to follow and things to avoid when you run top-level python code >> https://airflow.apache.org/docs/apache-airflow/stable/best-practices.html#top-level-python-code >> but if you want you can do anything. >> This is Python, we can't prevent you from doing pretty much anything with >> it if you want. There are no "truly" private methods in Python. Also you >> can do that: >> >> ``` >> while True: >> pass >> ``` >> >> and you will get your CPU at 100% too, >> >> J,. >> >> On Sun, Oct 3, 2021 at 11:22 PM Khalid Mammadov < >> [email protected]> wrote: >> >>> Hi Devs, >>> >>> >>> I was reviewing DAG class and noticed that almost all it's methods are >>> public. >>> >>> So, one can do something like below: >>> >>> with DAG(...) as dag: t1 = BashOperator(...) >>> >>> run_id = DagRun.generate_run_id(DagRunType.MANUAL, >>> datetime.utcnow()) >>> >>> >>> # This one works OK and create a DagRun for the Scheduler to pick up >>> dag.create_dagrun(state=DagRunState.QUEUED, run_id=run_id) >>> >>> # OR EVEN DO BELOW - which caused my laptop to run on 100% CPU >>> # dag.run() >>> >>> And I was wondering if this is intentional and/or expected behavior? >>> >>> >>> Thanks, >>> >>> Khalid >>> >>
