@tamara : Correct, we are now proposing to remove overriding the pre/post
execute
>Quick question if I am understanding the proposed change correctly.
What you want to remove is overriding the pre/post execute when creating
> custom operators:
>
> class MyOperator(BaseOperator):
>
> ...
>
>
Yeah. I am convinced by Bolke's and Constance posts. Changing my vote to
-0.9.
On Sun, Mar 30, 2025 at 8:25 PM Constance Martineau
wrote:
> Just to add to the discussion:
>
> Removing these overrides will disproportionately impact teams at companies
> with more than a handful of Airflow users. U
Sane points, keeping it for now :)
On Mon, 31 Mar 2025 at 00:00, Jarek Potiuk wrote:
> Yeah. I am convinced by Bolke's and Constance posts. Changing my vote to
> -0.9.
>
> On Sun, Mar 30, 2025 at 8:25 PM Constance Martineau
> wrote:
>
> > Just to add to the discussion:
> >
> > Removing these ov
Just to add to the discussion:
Removing these overrides will disproportionately impact teams at companies
with more than a handful of Airflow users. Unless there’s a clear benefit
to removing them *and* a well-defined migration path, I don’t think it’s
worth the disruption. +1 to Bolke’s points.
+1 to Bolke's points
niedz., 30 mar 2025, 10:30 użytkownik Bolke de Bruin
napisał:
> I would be in favor of removing the experimental feature of the constructor
> arguments, but I don't understand the reasoning for removing the override.
> It is a breaking change from something that was there si
I would be in favor of removing the experimental feature of the constructor
arguments, but I don't understand the reasoning for removing the override.
It is a breaking change from something that was there since 1.X so not
really experimental anymore. I think you might underestimate how much it is
u
No, @run_if / @skip_if uses pre_execute from task argument [1] not the the
method and is just a syntactic sugar. You can also do the following as an
example:
```
def skip_at_random(context):
if randint(0, 1) == 0:
raise AirflowSkipException()
t2 = BashOperator(task_id='conditional2',
Would this also break @run_if/@skip_if decorators?
Best,
Matt Block
> On Mar 28, 2025, at 3:44 PM, Tamara Fingerlin
> wrote:
>
> Hey :)
>
> Quick question if I am understanding the proposed change correctly.
>
> What you want to remove is overriding the pre/post execute when creating
> cust
Just one thing - the pre / post mechanisms are executed in-process of the
task rather than the DAG. So they are not equal to setup/teardown. Are you
proposing to remove the argument or the whole thing?
B.
On Fri, 28 Mar 2025 at 20:58, Jarek Potiuk wrote:
> Indeed. Post/pre overriding in sub-c
I think the current proposal is to remove the pre/post in the Base Operator
class (and overridability) and leave passing pre/post as constructor
arguments..
On Fri, Mar 28, 2025 at 9:20 PM Bolke de Bruin wrote:
> Just one thing - the pre / post mechanisms are executed in-process of the
> task ra
Indeed. Post/pre overriding in sub-classes should go away (and we could
even likely implement a ruff rule to auto-fix those if someone has a custom
executor. Sounds like 100% doable
But passing them as "cross-cutting concerns" via callable in a constructor
is pretty useful and not easily fixable f
>I think the ability of overriding pre_execute and post_execute in a
subclass can definitely go away. They are practically useles; you can just
put everything in execute, which always needs to exist in a BaseOperator
subclass anyway.
Yeah I am fine with removing that then. Anyone disagrees?
On Fr
I'd prefer a world without separate pre_execute and post_execute functions
- as pointed out in the PR, they make reasoning about DAGs more complex,
and can be error prone.
Having said that, I know there are multiple users relying on these
functionalities, so I'll bring up my usual - another breaki
Passing post_execute as an argument is somewhat useful for operators that don’t
support assets natively (most of them) but when you want to emit a dynamic
path. For example:
def _send_asset_event(context, result):
# Rendered value!
name = context["task"].output
# Trigger an event aga
I am in favor of dropping support as they essentially do the same -- and
setup & teardown is more "native" (first-class UI support)
On Fri, 28 Mar 2025 at 19:41, Kaxil Naik wrote:
> Hi team,
>
> Should we drop support for pre_execute and post_execute for AF 3.0? They
> are still marked as experi
15 matches
Mail list logo
