As all of the PRs have been reviewed and approved (thanks Ash!). I am proceeding with it now :). I hope this can move us a little closer to the ... future :).
On Mon, Sep 12, 2022 at 1:52 PM Jarek Potiuk <[email protected]> wrote: > Hey everyone, > > TL;DR; Just to make sure, this is all universally accepted - I am calling > for a lazy consensus on global enabling the PEP 563 "from __future__ import > annotations". > > I went a bit ahead of the consensus and prepared a lot of PRs - once again > apologies for any distress and "pressure" it could have caused with 47 PRs > opened (understandably that was a bit overwhelming). > > Discussion and comments about it here: > in https://lists.apache.org/thread/81fr042s5d3v17v83bpo24tnrr2pp0fp > > Summary of the proposal: > > * all the changes were automatically done by pyupgrade (which we already > use and have pre-commit configured for). > > * after reviewing and approving all the PRS I will combine them in two: > one for airflow and one for providers > > * I will merge those and cherry-pick the airflow one (not the provider one > as we don't modify/cherry-pick any changes there) for v2-4 branch > (carefully avoiding dragging-along unwanted changes from main) to make > cherry-picking easier for all 2.4* releases. > > * the benefits of it is simpler and more future-proof typing (for example > `list[str]` instead of `List[str]` and `| None` rather than `Optional`) . > This is the default typing style in Python 3.9+ already. > > * pyupgrade pre-commit will take care about automatically converting > typing for those who will continue using pre-3.9 style of typing - thus > also providing a nice learning experience for everyone (either they will > run pre-commit and it will be converted for them automatically or if they > don't - they will get CI pre-commit feedback). > > * After the change we will have a consistent typing approach in the whole > codebase. > > Since Ash had __actually_ reviewed the changes, I will merge those changes > tomorrow if I don't hear any opposition (the sooner, the better it will be > for the upcoming 2.4.0 rc and safer to avoid any unwanted changes to > drag-along). This discussion had been going on for a while, and it had no > major opposition (except maybe the mechanics of introducing the change) and > I think this is the right call to make. > > J. > >
