On Sat, Nov 30, 2019 at 1:33 AM Richard Damon Richard@damon-family.org wrote:
My personal feeling is that adding a significantly better name, and deprecating the old name (maybe never going past the state of documenting that it is deprecated and suggesting using the better name, one reason not to have an automatic removal of deprecated features) is viable if the name improvement is big enough.
Perhaps, IF the improvement is big enough. A marginal improvement is not worth all that hassle. And if you keep both names, you forever have people wondering what the difference is.
As an example, Python's threading module has duplicate names eg "current_thread" and "currentThread". The depreferred names are documented up to and including Python 2.7, but they still exist in the latest 3.x.
If we are going to use the existing web mentions, then Python would still be back as a 2.x version, and the language would be very static and 'old'
This applies only to bare renames. If a completely new feature is added, it's not going to run into this problem; you have the normal thing of "requires Python 3.5+", but that doesn't get more complicated as you add more features - if you have one that was introduced in 3.5 and another that was introduced in 3.7, then you need 3.7, it's that simple. Much more complicated when some things come and go, so the correct thing to do will change multiple times.
That doesn't answer the question of if the new name is enough better to be worth it.
Agreed. I don't see that it is, in this instance.
One issue is that since Python allows the user to monkey-patch library code, ANY expansion of name space is potentially breaking, Python has almost no namespace reserved for the language designers that users are allowed to intrude on (maybe dunders are reserved enough, but we don't want to be using dunders as part of user accessed API). Which means that even if we deprecate loads, the standard library should continue to use it and not the new load_string for awhile until it is felt safe that few people are monkey patching in a load_string member, and we can break the code.
I don't think we need to worry about people poking arbitrary values into a stdlib module and breaking things. If someone's doing that and their code breaks in Python 3.10, that's on them.