To expand on that thought, I find it easier to parse in cases like SQLAlchemy vs SqlAlchemy. It helps to visually indicate where that acronym stops and the next word starts.
________________________________ From: Ferruzzi, Dennis <ferru...@amazon.com.INVALID> Sent: Friday, February 4, 2022 11:20 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. 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<mailto: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<mailto: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<mailto: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
