> Note that while, as mentioned, ~= is a standard and well-supported operator, it is generally NOT RECOMMENDED to be used for Python version specification. It is also not recommended to use the equivalent expression composed with >= and <.
Interesting - could you point where it is specified that it is not recommended ? (Not that I am complaining, I understand that Python does not follow SemVer, but I look hard and have not found any place where anyone would say it's not recommended - that was the first time I hear it, but If I know that Python Packaging actually made that recommendation, I would be more than happy to just switch and not make any fuss about it. On Mon, Jul 7, 2025 at 1:12 PM Tzu-ping Chung <t...@astronomer.io.invalid> wrote: > Note that while, as mentioned, ~= is a standard and well-supported > operator, it is generally NOT RECOMMENDED to be used for Python version > specification. It is also not recommended to use the equivalent expression > composed with >= and <. > > Python does not use semantic versioning, and backward incompatible changes > are made in x.y releases (e.g. 3.10 can contain incompatibilities to 3.9). > Setting <4 (or any single-segment version) is therefore arbitrary and > divorced of any practicality. > > I would highly suggest Airflow to simply change ~= to a simple >= without > an upper limit. > > TP > > -- > Sent from my iPhone > > > On 7 Jul 2025, at 12:22, Amogh Desai <amoghdesai....@gmail.com> wrote: > > > > Thanks Jarek. > > > > I do not have a strong objection to either form. Both the ways are > > functionally the same and valid per PEP 440. > > > > If I had to slightly lean one way, I’d prefer ~=3.10 for its brevity and > > simplicity. That said, I would also understand why > > some might prefer the more explicit >=3.10,<4, especially in a big > project > > like ours where there are lot of newcomers > > coming in all the time. > > > > I am ok to go with whatever the community prefers here. I am more > > interested in consistency in one way or another. > > > > Thanks & Regards, > > Amogh Desai > > > > > >> On Mon, Jul 7, 2025 at 3:22 PM Pavankumar Gopidesu < > gopidesupa...@gmail.com> > >> wrote: > >> > >> Thanks Jarek, > >> > >> I am just catching up with this discussion. I agree that this is > >> unilaterally forcing us to make changes, though the one (~=3.10) is also > >> the standard one we have been using. > >> > >> I am in favour of using our existing convention ~=3.10. > >> > >> Pavan > >> > >>> On Mon, Jul 7, 2025 at 10:12 AM Jarek Potiuk <ja...@potiuk.com> wrote: > >>> > >>> Hello here, > >>> > >>> If you have not noticed - we have a little bit of drama because in the > >>> latest `uv` version, Astral unilaterally decided to make the `~=3.10` > >>> de-facto invalid specification. > >>> > >>> The `~=3.10` is a perfectly valid specification widely recognized as > >>> `>=3.10,<4` and specified like that (named "Compatible Release") in > >>> https://peps.python.org/pep-0440/#compatible-release and even if the > >>> wording in the PEP is slightly ambiguous for the semantics of it - it > is > >>> widely recognized, quite heavily used and all Python tooling properly > >>> interpret it in the way described above. > >>> > >>> Yet the Astral team decided - unilaterally, that this is an ambiguous > and > >>> misleading specification and started issuing a warning about it. > >> Initially, > >>> the warning was pretty mysterious for workspace, because it did not > tell > >>> which pyproject.toml it came from (we had it in all providers and > >> breeze) - > >>> so after they implemented a fix, this turned into about a 100 > >> unsilenceable > >>> warnings every time you run `uv sync`. This happened after I complained > >>> about this in the PR and proposed that there should be both - better > >>> message and a way to silence the warning for maintainers that they know > >>> what they are doing) - yet uv 7.9.19 just made the situation worse by > >>> ballooning the number of warnings and still not allowing to silence it. > >>> > >>> We are still waiting on a decision what Astral team will do in > >>> https://github.com/astral-sh/uv/issues/14422, Unfortunately there is > no > >>> community to make decisions there - this is a unilateral decision of > >> Astral > >>> team what they do, even if ~=3.10 is perfectly valid and recognized > >>> specification, that IMHO is not up to Astral team to make people change > >>> their way. > >>> > >>> So for now we are literally being forced by Astral to change the way we > >>> declare python compatibility - PR is here > >>> https://github.com/apache/airflow/pull/52967 . The way how `uv` > workflow > >>> works makes it impossible to keep `~=3.10` - because every time you run > >> `uv > >>> sync` - in our case literally several times a day you have 1.5 pages of > >>> warnings in your terminal. So it's not a "recommendation" - we are > forced > >>> to change it. > >>> > >>> I do not particularly like being forced like that - for the "PEP > >> compliant" > >>> and "standard" feature by the Astral team - but for now I created the > >>> temporary fix - and hopefully the decision will be reversed and we will > >> be > >>> able to silence the warning - if we choose to do so. > >>> > >>> Speaking of which: > >>> > >>> Assuming that we have a choice (we do not have it now) - what would be > >> your > >>> preference: > >>> > >>> * Should we continue using ~3.10 ? > >>> * Or should we switch to >=3.10,<4 ? > >>> > >>> I'd love to hear - regardless of the forceful change now - what is the > >>> preference of the community members. I have no "strong" preferences, I > >>> slightly prefer the `~3.10` as it is more concise. But I know others > >> might > >>> have a different preference. And assuming that the Astral team will > stop > >>> forcing us to "voluntarily choose" the latter, I would love that our > >>> community makes that choice on their own. > >>> > >>> What do you prefer? > >>> > >>> J. > >>> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > For additional commands, e-mail: dev-h...@airflow.apache.org > >
