Abdur-Rahmaan Janhangeer writes:
"Designed With Learning in Mind"
That's Python. Guido said so from the beginning, and in modern Python development we tend to favor full words with a consistent convention for separating them in multiword identifiers and so on. Syntax additions get fully bikeshedded; "tend to favor" is not acceptable there! Python is also developed mainly by volunteers, with a relatively conservative attitude toward additions to the stdlib. Some packages do get developed here on Python Ideas and Python Dev, and fast-tracked because their proponents are well-respected. Those tend to get quite a lot of attention to nomenclature ("bikeshedding", as it's called). But most aren't (and that includes most by famous proponents, too![1]) That means that some volunteer typically spends years polishing up their package to *their* satisfaction, and by the time it gets added it has a substantial following and a substantial installed base (if it didn't, it likely wouldn't get added), making backward compatibility a thing. At that point adding synonyms may backfire. People using synonyms run into trouble, they ask on StackExchange, and the grizzled old folks (who constitute a large fraction of the People Who Answer) will go "WTF is this?" and move on to a question they can answer off the top of their heads. You don't have to like it. I don't think anybody likes suboptimal naming, they just like it better than they like backward-incompatible renames or namespace pollution. You can't really expect others to be happy with wholesale changes to the environment, even if they're fully backward compatible as the proposals to add aliases for json.loads and calendar.calendar are. (As usual, you can say "I just want these two," and we'll respond "OK, but the community as a whole will want a million of them, we all have our favorites, and if we accept yours, how do we deny theirs?") You can always just write wrapper modules that do nothing but rename any identifiers you think are unintuitive. It would be interesting to see how much uptake you get from new users. (I exclude existing users because, however much they *like* your names, they are likely to be biased against the changes by backward compatibility with their own code and with third-party code -- not really a fair test. Although if you get a lot of uptake there it would be a strong recommendation.) Footnotes: [1] For example, consider the dates of implementation of PEPs 3107 and 484. 3107 wasn't written by Guido, but he wanted and advocated it, and AIUI he always intended it to support something like 484.