On 11/29/19 7:21 AM, Chris Angelico wrote: > On Fri, Nov 29, 2019 at 9:48 PM Abdur-Rahmaan Janhangeer > <arj.pyt...@gmail.com> wrote: >> One of them can maybe be deprectated >> >> json.load(<string here>) >> >> for file: >> >> json.load(file=<file obj>) >> > Deprecation is not a solution. You're still going to have stuff out > there using the old name (Stack Overflow posts, blogs, articles, > books, etc etc etc etc), and people *will* have to learn the meaning > of both. Additionally, churn like this - renaming things for no reason > other than "the new name is somehow better" - tends to create the > sense that the language is constantly in flux, and that today's code > is going to be broken tomorrow. Imagine a Stack Overflow answer that > has to be edited to say "For Python versions up to 3.8, use > json.loads; for versions 3.9 and up, use json.load_string", and then > if it uses a couple of other APIs that have been renamed, it needs to > multiply that out exponentially... no thanks. I get enough of that > from React.js. > > -1 on renaming. -1 on deprecating. -1 on creating an unnecessary alias. > > ChrisA
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. 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' That doesn't answer the question of if the new name is enough better to be worth it. 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. -- Richard Damon _______________________________________________ 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/RCET2DC6CCKEH2XDPE7WXXY7NBLD54LO/ Code of Conduct: http://python.org/psf/codeofconduct/
