Fair point, Dennis. To be clear, I wasn't vetoing enabling PT006, it just wasn't my personal preference.
If folks can agree on enabling 06, I will not push against it. Thanks & Regards, Amogh Desai On Mon, Oct 20, 2025 at 10:58 PM Dennis Ferruzzi <[email protected]> wrote: > I have someone willing to do the work to implement one or both but stopped > because of folks saying they didn't think the rules were worth implementing. > > Looking through the comments here, I think I want to tell them to go ahead > and finish 06 ((using a tuple[str] instead of a coma-separated-string for > parameterized names)) and leave 07 alone ((we currently usually use a > list[tuple] for the values, but 07 would enforce tuple[tuple])) > > I don't want to tell a new contributor to go ahead then have someone veto > their PR, that's a rough first commit experience and likely demoralizing. > > On 2025/10/16 11:59:48 Amogh Desai wrote: > > > 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. > > > > Thanks Daniel, that is precisely what I was referring to. > > > > I have no strong objection to either side and wouldn't mind using > whatever > > the repo rules enforce. I personally think both of those rules won't add > > much > > value (atleast to me) but we do not have to agree here. > > > > Thanks & Regards, > > Amogh Desai > > > > > > On Thu, Oct 16, 2025 at 5:23 AM Kataria, Ramit <[email protected]> > wrote: > > > > > I agree with Wei: my personal preference would be to not use a > > > comma-separated string (enable PT006) but I’m not too strongly > opinionated > > > about this. As for PT007, I’m indifferent about tuples or lists for the > > > values. > > > > > > Ramit > > > > > > From: Jarek Potiuk <[email protected]> > > > Date: Wednesday, October 15, 2025 at 10:29 AM > > > To: [email protected] <[email protected]> > > > Cc: Daniel Standish <[email protected]> > > > Subject: RE: [EXT] [Lazy Concensus] Wrap up the Pydocstyle project > > > > > > 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] > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
