That’s about the timescale for the threading module. And I did a quick search for threading.currentThread and came across this:
The text itself is a bit messed up but you can clearly see that this is a student’s code, and the repository includes some text copied and pasted from the instructions. And the instructions use the old name in the hint. That means, fourteen years after Python 2.6 came out (that repository is a year old), students are being taught using the old names.
When I say “remain forever”, I really truly mean that. Otherwise it’s option 1 with a long gap. The costs of maintaining aliases aren’t huge, but they aren’t zero either:
- More code in the stdlib
- More tests, making sure to test both aliases properly (you could assert that
threading.currentThread is threading.current_threadbut that fails once you add a deprecation warning to the old name) - Blog posts, Stack Overflow answers, and forum recommendations, all divided among the different names
- Confusion when people correlate different sources and find different names
- Confusion when people explore the object and ask “what’s the difference between these?”. This is very real; I had to spend some time looking up the
event.srcElementattribute on a JavaScript event object, only to find out that it’s a deprecated alias forevent.target. - More difficult code searches - “how extensively is this attribute used?” now requires that you search for both names
- Etcetera.
Each one might not seem like a huge cost, but for comparison, neither are the costs of the current situation:
- It’s harder to handwrite code without tab completion, as you have to remember (or look up) which name to use
- It’s harder to spot errors. If you write
dict.fromKeys(...)then you should know for sure that it’s wrong (though - without looking it up - do you know whether it’sfrom_keysorfromkeys?). Having inconsistent names means that more naming conventions “look right” to your eye.
But at least there’s less confusion.