Don't use builtin len/bytes as variable

[gopidesupavan]

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[amoghrajesh]

Yeah nice. If original one was backported to v3 branch, could you do this one too?

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 6eca233 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[potiuk]

needs manual backportin @gopidesupavan :)

[gopidesupavan]

needs manual backportin @gopidesupavan :)

Yeah will check :)

[ashb]

This sort of change generally shouldn't be backported -- it's only a stylistic change and not a bug fix.

[potiuk]

This sort of change generally shouldn't be backported -- it's only a stylistic change and not a bug fix.

I think it really depends - especially now when we are cherry-picking things relatively quickly after they are merged.

if you want to cherry-pick changes from related code (and in this case we actually do) cherry-picking such changes is good as it allows to avoid conflicts. This has always been the same issue with "breeze" and I've always had huge problem and a lot of lost time for conflicts resolving when things like that were not cherry-picked.

I'd say the rule of thumb should be a bit less dogmatic and a bit more pragmatic - the rule as I see it should be a bit more nuanced than "bug-fixes" only. We should simply always cherry pick:

• results of automated refactorings that have very low risks (in the areas that are likely to have cherry-picks)
• bug-fixes (of course)
• doc changes (when they are improvements or filling gaps)
• dev tool changes (every time we did not, it resulted in hours of my time when things were breaking and I tried to reconcile it)

That's the rule I am following at least. Maybe we should discuss it at the devlist because I think there might be different perspectives here and opinions

[potiuk]

Actually - let me start a discussion on it, this is important that we get to alignment so rather than complaining on others doing things they think is right, we should agree what rules we should follow - and follow it.

[github-actions]

Backport successfully created: v3-0-test

Status	Branch	Result
✅	v3-0-test