To be honest - the most important thing is to be consistent. And willingness (and drive) of someone to make it happen. There is very little chance people agree on personal preferences for that, and arguments and discussions on what is more or less readable can take strange turns.
I have my own preferences for personal projects, but I would rely on whoever takes their own time to implement those and automate it via ruff rules (except if it makes the code reads really, really badly readable) and I will never complain if it's just a "preference". Basically my rule is: "I do not want to even think about it - even less to discuss it, I want it to happen ideally automatically, same way for all committers and contributors". It was a blessing at some point of time when we turned to `black` for code formatting - and all such discussions stopped (we had quite a few), because black had almost 0 configurability (precisely for that reason - to stop such discussions). I even bumped fists with Łukasz Langa at Python Meetup in Warsaw after he introduced black as it was (before ruff came and took over) so refreshing :). So If someone finds time to enable some rules, and update all the occurences in a code, I am happy to follow whatever ruff tells me to do (ideally - whatever ruff does automatically). J. On Wed, Oct 15, 2025 at 7:27 PM Daniel Standish via dev < [email protected]> wrote: > 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] > > > > >
