+1 for BranchSqlOperator, easier to read imho On Fri, 4 Feb 2022 at 20:39, Howard Yoo <howard...@gmail.com> wrote:
> Just my two cents : Have preference for not capitalizing all the > characters in abbrevications, so > BranchSqlOperator is totally fine with me. It's also easier to type (less > pressing on Caps key!), and also Might be easier to read and check. > +1 on that. > > - Howard > > On Fri, Feb 4, 2022 at 1:20 PM Ferruzzi, Dennis > <ferru...@amazon.com.invalid> wrote: > >> In December Elad organized a community project ( >> https://github.com/apache/airflow/issues/20139) which included >> un-PEP-8-ing the Amazon provider package, the all-caps acronyms you see >> there are/should all be deprecated. >> >> That said, I do find it easier to read as `BranchSqlOperator`, so >> that format would be my vote if I had one. >> >> >> *From:* Jarek Potiuk <ja...@potiuk.com> >> *Sent:* Friday, February 4, 2022 7:16 AM >> *To:* dev@airflow.apache.org >> *Cc:* Felix Uellendall >> *Subject:* RE: [EXTERNAL] [DISCUSS] how to name classes with >> abbreviations? >> >> >> *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. >> >> Surprisingly, as opinionated as I often am, I am happy to follow whatever >> rules others agree with here :). >> >> Even if we agree that "either is ok" and we mix them and keep them >> inconsistent and even if someone we do this and sometimes that. I simply do >> not see huge value in standardizing this. >> >> Why? >> >> Following the "human language" that you mentioned, Bas (as I see it at >> least), the right answer is "it depends". >> >> IMHO in human language the capitalization rules for acronyms vary and are >> full of exceptions and depend on context. Some acronyms are better >> CAPITALIZED but for some it's perfectly ok to be CapWorded and which one >> is better "felt" depends on who you are, what background and experience you >> have, and whether English is your native language. >> For example, for me TCP is clearly very bad when CapWorded as 'Tcp' , but >> Http is far more pleasant than HTTP. And (just to anticipate arguments) >> it's not only about the length, it's also about some past experiences and >> how many of each I've been intimately familiar with (i.e. how many >> documents and code I read and written on each mostly). >> >> So just to protect my sanity I developed a blind spot and for me either >> is OK and even if we have no consistency, I simply don't care :). That also >> saves a lot of mental effort to discuss and think about it, to be perfectly >> honest. >> >> So I will follow whatever rule others feel strong about. >> >> J. >> >> >> >> On Fri, Feb 4, 2022 at 11:07 AM Bas Harenslak <b...@astronomer.io.invalid> >> wrote: >> >>> Thanks for opening this discussion, hopefully we can improve >>> consistency, regardless the outcome. >>> >>> +1 for capitalizing abbreviations. IMO since abbreviations are written >>> capitalised in human language, using the same convention in code gives >>> clarity. >>> >>> Bas >>> >>> On 4 Feb 2022, at 07:26, Felix Uellendall <felue...@pm.me.INVALID> >>> wrote: >>> >>> Sorry in this case I would be NOT in favor of pep8. I misread it. >>> >>> -feluelle >>> >>> >>> Sent from ProtonMail for iOS >>> >>> >>> On Fri, Feb 4, 2022 at 07:22, Felix Uellendall <felue...@pm.me.INVALID> >>> wrote: >>> >>> I am in favor of pep8 guidelines. I think it makes sense to clearly see >>> separation between words/tokens. For me uppercase is harder to read and I >>> don’t like getting screamed at. As long as there is documentation, this can >>> be written there correctly as you can split it like normal words (by >>> spaces). >>> >>> -feluelle >>> >>> >>> Sent from ProtonMail for iOS >>> >>> >>> On Fri, Feb 4, 2022 at 01:46, Daniel Standish < >>> daniel.stand...@astronomer.io.INVALID> wrote: >>> >>> How should we name, for example, an operator such as `BranchSQLOperator`? >>> >>> This operator used to be called `BranchSqlOperator` but at some point in >>> the past was renamed. >>> >>> Meanwhile we have SparkSqlOperator which uses the other convention. >>> >>> And we have `EmrBaseSensor`, and `EMRContainerOperator` coexisting. >>> >>> On this SO post >>> <https://stackoverflow.com/questions/2853531/how-do-you-pep-8-name-a-class-whose-name-is-an-acronym> >>> you can find argument on both sides of the debate. >>> >>> On one side you have a quote from PEP-8: >>> >>> Note: When using abbreviations in CapWords, capitalize all the letters >>>> of the abbreviation. Thus HTTPServerError is better than >>>> HttpServerError. >>>> >>> >>> On the other side you have an example like this: >>> >>> class NASAJPL: >>> >>> >>> vs >>> >>>> class NasaJPL >>> >>> vs >>> >>>> class NasaJpl >>> >>> >>> By one argument, option 3 is most readable because the "tokens" are >>> clearly separated (i.e. nasa and JPL) -- and certainly in some IDEs this >>> can be a great benefit. >>> >>> And perhaps the argument for option 2 is you say "nasa" and "J-P-L" not >>> "nasa" and "jipple" -- in contrast with SQL where reasonable people say >>> "sequel" and not "ess queue ell". >>> >>> This comes up pretty regularly, and I think we ought to make a decision >>> and do some pre-commit work to enforce (with an exception list a la >>> spelling-wordlist.txt) the decision. >>> >>> So, please consider debate kicked off, and have at it. >>> >>> Thanks >>> >>> >>> >>> >>> >>> >>> >>>
