I think we are at this point because AIP-21 handles more file paths rather than class names. Case 6 in AIP-21 says to make individual decisions and it says "consistency trumps compatibility." I'm in favor of: Gcs over GCS, Emr over EMR, Sql over SQL.
To mention we also have operators like SqlToS3Operator and I think it's much easier to read then SQLToS3Operator. On Fri, Feb 4, 2022 at 9:44 PM Tomasz Urbaszek <turbas...@apache.org> wrote: > +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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>
