We in the software developer world believe that a programming language, let's say, Python, is a single language, which will look the same everywhere. Python in particular encourages this idea with their, "there is only one way to do it" philosophy. Yet as people hop from company to company, from team to team, from repo to repo, we see differences on how the language is used.
People react differently when they find differences. One common one is to say that some people are using Python incorrectly. You hear expressions like "it is not pythonic", "your Java is showing", "these are not best practices". If any analysis is offered, the argument usually boils down to, "you are doing it wrong; I am doing it right." This can lead to hurt feelings or even fights, depending on the personalities involved.
To me, this is another place where technology discourse hides social dynamics. Having a better perception of reality helps to better discuss what is going on and how to address things.
In this case, we should think of Python as a natural language, and each company or team having its own language dialect. Dialects are naturally occurring in languages used by groups of people. Developer teams are like villeges. So it will naturally occur that dialects will develop.
Natural languages, like English or Spanish, are held together by common understanding, a common core of grammar, vocabulary, spelling, and idioms. Yet what people actually speak is a dialect. People speak many dialects, depending on the group of people that they are surrounded. We usually speak a family dialect, called an idiolect, where within your family you call dinner, "chum chum time." In your town your may speak Southern English. At work you will speak communicator's English. When you go to a professional conference, you speek academic and business English.
There isn't a correct English; as long as you communicate with others, every dialect or idiolect is valid. What matters is communications. Can you communicate with each other? Then it is successful.
That is what the diversity of Pythons that you see in the world are: different dialects. Python is like English. Just like English, I, as an American, can understand someone from Australia. Yet there will be some sounds and idioms that are different. That is okay: if you really want to understand your Australian friend, you will ask questions on expressions or word you don't understand. They will do the same. Your mutual understanding will grow.
If I move to Australia, as an American, I can insist in writing in my teenage dialect. It is English. I may even think that an idiom like "it's so fetch"x is a good to communicate with Australians. But they won't understand it. Insisting that Australians should speak like North Americans in Australia makes no sense.
This is what we do when we insist in using Python idioms that are not part of a repo's dialect. We are not adapting to the new environment. We are being unreasonable, more out of pride than anything else.
What I propose is to approach team programming dialects the same way we approach natural languages: we adapt to make sure that we can communicate well within the group.
When you join a new team who heavily uses decorators, they are not doing it wrong, this is the team's dialect. Learn the idiom to adapt.
Learn to gently introduce new idioms too. Let's say that you love list comprehensions, but the team doesn't use them. It doesn't matter how cool they are, or how it is so close to a mathematical way to define a set. If no one can understand your code to fix it, it is like saying "this is butter to butterflies" in an English conversation. It increases confusion, rather than understanding.
Why should we adpat and gently introduce new idioms? Because we need to preserve the team's dialect. And we want to preserve ours team's dialect because this is how the team has evolved to communicate with each other. In business terms, thousands of worker hours have been spent to reach this point.
When we develop coding guidelines, we should keep this in mind. We should be more like linguists in that grammars describe how the language is use; not how it should be used. Same with code guidelines: it should describe the practices that are currently done in the team.
There is an illusion that if we introduce coding standards, the standard will then be use to force people to adopt it. Such a project can create a lot of strife and resentment. At the end of the day it may be ignored. It may even create more inconsistencies because some people may use the standard and others don't.
And we should let languages evolve. Back to list comprehensions: maybe it didn't take off immediately, but as people tried it out, they understood it, and liked it. So now it is part of the dialect. Now it can be included in the coding guidelines.
Thinking about your team having a programming dialect helps to have a better perspective on how to successfully join a team and stear it towards different idioms.