Ricky Teachey writes: > Leading by example of not sticking forever with obfuscated naming.
We do push back against obfuscated naming, including abbreviations like loads, but forward-looking, not backward-looking. There's also the problem in the stdlib that often a requirement for a module to be added is that it have a large following. In those cases the author may or may not have followed what we consider good naming practices, but they were good enough for the users. > So I'm still +1. Just add the better named function as an option > and be done with it; other than adding it to the docs, leave > everything else as it is. I would find this very annoying, because I believe it would lead to widespread namespace pollution. I use dir() a lot to remind myself of APIs, and aliases that would confuse me and slow reading (I'm old enough to have vision issues) would anger me. Using dir() works for me because I read docs before I start typing code (hentai, I know), and have a relatively good memory after one or two readings. I don't know how many people have those characteristics, though. There's second aspect of namespace pollution, which is that users will frequently use plausible alternatives for their own value-added APIs. I don't know if this actually causes confusion, though. > No one sees that example as a signal that it's a good idea to do > objectively bad naming, like loads() does. But someone sees loads() and > thinks, "ah, short names are really good", and go with prof() rather than > process_file(). People who think short names are good are more worried about typing them than anything else in my experience. They're not imitating anybody, they're optimizing the code in front of them. > So here I'm really talking about what I'm calling obfuscated names, > not necessarily names that aren't as intuitive as they could be. One person's unintuitive can easily be another's obfuscated. pickle.dump() is *obfuscated* to anybody old enough to have used "set limit core unlimited" (even if they were born in 2010). For those of us old enough to remember "can't eat just one", "memory dump" (of which "core dump" is a special case) is an extremely strong association. I'm basically -1 on any aliasing. I think there's way too many that have been proposed. I can't see a way limit them that doesn't read "screw you" to the proposals that are denied, and it would be a burden on me, it would cause confusion, and I don't think the benefits are likely to be great. Those are all subjective priors, so I could be moved if some proponent is willing to go through the last five years of Python List, Python Ideas, Python Dev, and the tracker and provide a list of aliasing and renaming proposals, and show that the likely level of namespace pollution is low. _______________________________________________ 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/UOTHYVYLM5W57VTPGF47H24INW6ZD4WO/ Code of Conduct: http://python.org/psf/codeofconduct/
