> I'd be +1 on adding a better named alias for loading strings to all of these libraries.
Including the ones that aren’t in the stdlib? If so, how do we do that?
Leading by example of not sticking forever with obfuscated naming.
So the Very Good Thing isn’t actually as good... you need to argue that it’s compelling enough to be worth the tradeoff anyway, rather than ignoring the cost and arguing as if we had a time machine
I ignored them because none of those issues seem like a big deal to me. But I'm also mindful I've been at this much much less time than most of you.
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. New people will start using it (because it is so much more obvious what it is) and their understanding, and the new code they write mimicking the standard library, will be improved. And later other libraries will follow the lead that better names for things are very very important.
Obfuscated names have a huge tendency to push people away.
As a side note: I found it much more confusing when I learned pickle that the opposite of load was not store, but dump. To me, dump sounds like a debugging function that would format a pickle with all relevant details and print it to stderr (much like dis), not a function you’d use to convert an object to a pickle and save in a file.
That would be an example of a name that might be unintuitive (I think of a dump truck and intuit it right away, but to each his own). It isn't an OBFUSCATED name.
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().
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.