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.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/7M5YNSWNAH57FSNIWRUDSUUVOMEOBHEP/
Code of Conduct: http://python.org/psf/codeofconduct/
