To stir the pot a bit more, as someone pointed out, yes we have `DAG` but
we also have `dag` because of the decorator. So if we wanted to follow code
convention, is it `DAG` or `dag`?

I really don't want to start using `Dag` in code but I guess it is pythonic
since it's technically a class name...

Either way I can add it is as Option D: Prefer Dag in docs, use Dag for
class/import and alias DAG (for backcompat reasons)

On Fri, Oct 17, 2025 at 10:34 AM Daniel Standish via dev <
[email protected]> wrote:

> I’m not really proposing to rename to Dag in code.
>
> I’m mainly saying Dag in docs doesn’t feel right given that’s not the
> object in code.
>
> Just one man’s take.
>
> On Fri, Oct 17, 2025 at 4:12 AM Jarek Potiuk <[email protected]> wrote:
>
> > > Old habits but I am fine with DAG and DAGs :)
> >
> > He, he: "we've always been doing it this way" to the fullest ;).
> >
> > But ... responding to Daniel's concern. I would be indeed for having
> those
> > two options:
> >
> > 2a) Dag in docs, DAG in code
> > 2b) Dag in docs, Dag in code  (with DAG alias - no deprecation as it will
> > break millions of Dags out there).
> >
> > That would be "proper" from the pure correctness point of view (DAG is
> not
> > a PEP-compliant name we have for the class).
> >
> > But only as long as we stress the implication and consequences so that
> > anyone voting realises what those practical consequences are.
> >
> > To be perfectly honest - even if I think it's a good idea to add this
> > option to vote, I am not in favour of it personally - precisely because
> of
> > the consequences.
> >
> > If we allow both `Dag` and `DAG` in the code the practical implications
> are
> > super messy IMHO. If people start using "Dag" in their code and publish
> it,
> > it will not work for pre-rename versions of Airflow, If we remove DAG
> > eventually - all the published code with DAG will not work for future
> > versions of Airflow.  This will have a huge impact on issues raised by
> > users and is generally "messy" - the overall implication of such code
> > change will be that a number of users will consider Airflow Dags broken.
> >
> > In this case I would strongly prefer to follow PEP-20, Python Zen:
> > https://peps.python.org/pep-0020/ - namely those two points:
> >
> > * There should be one-- and preferably only one --obvious way to do it.
> > * Although practicality beats purity.
> >
> > So - as long as we realise the consequences, possibly we should add the
> > option of "Dag in docs, Dag in the code" to vote on to address Daniel's
> > concerns.
> >
> > J.
> >
> > On Fri, Oct 17, 2025 at 12:43 PM Kaxil Naik <[email protected]> wrote:
> >
> > > Old habits but I am fine with DAG and DAGs :)
> > >
> > > On Fri, 17 Oct 2025 at 07:18, Amogh Desai <[email protected]>
> wrote:
> > >
> > > > Not to explode this thread further, but "Dag" seems to be a good
> middle
> > > > ground to me for the reasons mentioned above by Constance and AI.
> > > >
> > > > And, "DAG" is the worst of all for me to use in day to day speech.
> > > >
> > > > Thanks & Regards,
> > > > Amogh Desai
> > > >
> > > >
> > > > On Fri, Oct 17, 2025 at 12:14 AM Daniel Standish via dev <
> > > > [email protected]> wrote:
> > > >
> > > > > It's not an easy call.  But I think my take is that Dag would make
> > > sense
> > > > if
> > > > > we rename the DAG object to Dag.  But if we do not then it does not
> > > seem
> > > > > right to style it as Dag.
> > > > >
> > > > > If we want to rename the actual object from DAG to Dag, then sure.
> > > > >
> > > > > If we stay as DAG, I just like being able to write dag midsentence
> > > > because
> > > > > that is how we do it normally when writing about dags.  And DAGs
> > looks
> > > > > really awkward.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, Oct 16, 2025 at 3:12 AM Amogh Desai <[email protected]
> >
> > > > wrote:
> > > > >
> > > > > > Thanks for sending this notice, Constance.
> > > > > >
> > > > > > The older thread just blew up with too many opinions and calling
> > > > > > a formal vote is the way to go.
> > > > > >
> > > > > > Thanks & Regards,
> > > > > > Amogh Desai
> > > > > >
> > > > > >
> > > > > > On Thu, Oct 16, 2025 at 1:08 AM Jarek Potiuk <[email protected]>
> > > wrote:
> > > > > >
> > > > > > > Very nice summary ! Thanks Constance :)
> > > > > > >
> > > > > > > On Wed, Oct 15, 2025 at 9:27 PM Constance Martineau via dev <
> > > > > > > [email protected]> wrote:
> > > > > > >
> > > > > > > > Reviving this discussion after the canceled vote:
> > > > > > > >
> > https://lists.apache.org/thread/q7zdogwb76jko3vwz7tlsnl2cn3h3vg9
> > > > > > > >
> > > > > > > > As mentioned earlier, I plan to *formally call a vote on
> > Monday*
> > > to
> > > > > > > > finalize how we refer to Airflow workflows in writing (docs,
> > > > > tutorials,
> > > > > > > and
> > > > > > > > blog posts).
> > > > > > > >
> > > > > > > > This will *not* affect code (DAG and dag remain as-is in APIs
> > and
> > > > > > > > decorators). The goal is to set a clear convention for prose
> so
> > > > > > > > contributors and vendors can align their content accordingly
> > > > > > > >
> > > > > > > > Why this matters: We’ve had inconsistent terminology across
> > docs
> > > > and
> > > > > > > > repeated PR debates over capitalization. Standardizing will
> > make
> > > > our
> > > > > > > > writing clearer, strengthen the Airflow brand, and give
> > external
> > > > > > > > stakeholders a single reference to follow.
> > > > > > > >
> > > > > > > > Options for standardization:
> > > > > > > >
> > > > > > > >
> > > > > > > >    1. DAG (all caps)
> > > > > > > >       - Matches existing imports (from airflow.sdk import
> DAG)
> > > and
> > > > > the
> > > > > > > >       broader ecosystem.
> > > > > > > >       - Keeps a nod to the original meaning ("directed
> acyclic
> > > > > graph")
> > > > > > > >       which still fits conceptually even if we later allow
> more
> > > > > > flexible
> > > > > > > > graph
> > > > > > > >       types
> > > > > > > >       - Counterpoint: Feels overly technical or academic for
> > many
> > > > > > readers
> > > > > > > >    2. Dag (capitalized)
> > > > > > > >       - Treats it as an Airflow-specific concept ("a Dag" =
> an
> > > > > Airflow
> > > > > > > >       workflow)
> > > > > > > >       - Reads more naturally in writing than all caps.
> > > > > > > >       - Counterpoint: Neither a class name nor a standard
> word
> > > > form,
> > > > > so
> > > > > > > it
> > > > > > > >       can feel inconsistent
> > > > > > > >    3. dag (lowercase)
> > > > > > > >       - Reads like a common noun in Airflow vocabulary
> > > > > > > >       - Matches Python identifiers (dag_id, dag.run_id) and
> > > blends
> > > > > > > cleanly
> > > > > > > >       into text
> > > > > > > >       - Counterpoint: Loses the visual link to the acronym
> and
> > > > class
> > > > > > name
> > > > > > > >
> > > > > > > > If anyone has other proposals, please add them here and I'll
> > > > include
> > > > > > them
> > > > > > > > when the vote opens Monday. Please see the collapsed section
> > for
> > > > more
> > > > > > > > details and background.
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Constance
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Proposed framing for the vote:
> > > > > > > >
> > > > > > > >    - Option A: Prefer dag in docs; use DAG only when
> referring
> > to
> > > > the
> > > > > > > >    class/import
> > > > > > > >    - Option B: Prefer Dag in docs; use DAG only for the
> > > > class/import
> > > > > > > >    - Option C: Keep DAG as the standard everywhere (status
> quo)
> > > > > > > >
> > > > > > > > Option with the most votes wins. You can vote between -1 to
> +1
> > > for
> > > > > any
> > > > > > of
> > > > > > > > the three options, and everyone will be encouraged to vote.
> > > > > > > >
> > > > > > > > Summary of viewpoints so far (AI- generated):
> > > > > > > >
> > > > > > > >    - "dag"  — clean, user-friendly, Pythonic, avoids shouting
> > the
> > > > > > acronym
> > > > > > > >    - "DAG" — consistent with current APIs and historical
> > context
> > > > > > > >    - "Dag" — middle ground; distinguishes the concept from
> the
> > > > > acronym
> > > > > > > >    while keeping it recognizable
> > > > > > > >
> > > > > > > > Links:
> > > > > > > >
> > > > > > > >    -
> > > > > https://lists.apache.org/thread/lktrzqkzrpvc1cyctxz7zxfmc0fwtq2j
> > > > > > > >    -
> > > > > https://lists.apache.org/thread/5fn1n188f99jspt627qhqsp2pznq545s
> > > > > > > >    -
> > > > > https://lists.apache.org/thread/q7zdogwb76jko3vwz7tlsnl2cn3h3vg9
> > > > > > > >
> > > > > > > > Constance
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to