Yeah re personal preference, I think maybe what Amogh meant was that, it's not of great consequence / impact so it is an area where we can leave it to the individual developer to choose.
There are areas like this where some ruff rules are just overly picky so we disable them and allow contributors to have some flexibility, and this is maybe what he meant by preference. On Wed, Oct 15, 2025 at 10:11 AM Ferruzzi, Dennis <[email protected]> wrote: > > I do not see a high value in enabling PT006/7, it is a matter of > personal preference > > > To be the devil's advocate here, ruff is all about enforcing personal > preference. Double quotes vs single quotes, blank lines before or after > docstrings, etc are all personal preferences we've decided to standardize > on. So I don't think that's a particularly valid argument against enabling > them. > > > - ferruzzi > > > ________________________________ > From: Wei Lee <[email protected]> > Sent: Wednesday, October 15, 2025 1:51 AM > To: [email protected] > Subject: RE: [EXT] [Lazy Concensus] Wrap up the Pydocstyle project > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. > Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez > pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que > le contenu ne présente aucun risque. > > > > I think we should enable PT006. I always feel that using a comma-separated > string is not a good idea. > As for PT007, I like it but have no strong opinion. I'm okay with PT007 > not being enabled. > > Best, > Wei > > > On Oct 15, 2025, at 2:18 PM, Amogh Desai <[email protected]> wrote: > > > > No comment needed but I do not see a high value in enabling PT006/7, it > > is a matter of personal preference (I tend to be more comfortable with > using > > ` [("var1", expected2), ("var2", expected2)],` myself) > > > > > > Thanks & Regards, > > Amogh Desai > > > > > > On Wed, Oct 15, 2025 at 6:13 AM Ferruzzi, Dennis <[email protected]> > > wrote: > > > >> RE: https://github.com/apache/airflow/issues/40567 > >> > >> Rule PT011 is in progress - thanks to contributor xchwan< > >> https://github.com/xchwan> - which leaves only rules PT006 and PT007. > >> Kaxil [1] and Ash [2] have both expressed a dislike for those two rules, > >> perhaps others have as well, so I want to put it out there for lazy > >> consensus. I propose we drop those two from the project and mark it > done > >> once PT011 is completed. > >> > >> The "issue" in a nutshell: > >> > >> Enabling: > >> > >> > >> PT006 | @pytest.mark.parametrize names should be a tuple > >> PT007 | @pytest.mark.parametrize values should be a tuple > >> > >> would change: > >> > >> > >> @pytest.mark.parametrize( > >> ("var, expected"), > >> [("var1", expected2), ("var2", expected2)], > >> ) > >> > >> > >> to > >> > >> > >> @pytest.mark.parametrize( > >> ("var", "expected"), > >> (("var1", expected2), ("var2", expected2)), > >> ) > >> > >> Specifically: the names would be enforced as a `tuple[str]` instead of > >> `Iterable[str] | comma-delimited-str` and the values would be enforced > as > >> `tuple[Any]` instead of `Iterable[Any] `. > >> > >> > >> The vote: > >> > >> If anyone feels strongly that these two remaining rules SHOULD be > >> implemented, this is your chance. If nobody makes an argument for > enabling > >> them, then consider lazy consensus met in 72 hours (Friday 17 Oct at > 18:00 > >> Pacific Time) or when PT011 is finalized, whichever is longer. > >> > >> [1] https://github.com/apache/airflow/pull/48114 > >> [2] https://github.com/apache/airflow/pull/56395 > >> > >> > >> - ferruzzi > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
