> > I would prefer "one right way to do it", but I also don't see a compelling > reason to deprecate the old interface. >
For me, the reason to eventually deprecate the old interface is to help new developers learning a new codebase. When these developers have been taught to use response.headers but inevitably happen upon the old interface, there will be a period of head scratching, diving into docs, code, whatever to learn what this means only to come to the conclusion that it is an alias. To me, that is an experience that could be improved. The other benefit I see in deprecating the old interface is that new developers don't need to learn or care how this fits in a particular organization's coding style. Perhaps the organization requires using only response.headers. Someone that uses the old interface out of habit will need to unlearn this habit and perhaps deal with the frustration that comes up during a review to fix it. Consolidating to only a single interface would resolve both of these, IMO. I'm quite happy to see the deprecation occur over a longer time than normal, so I think the "may be deprecated in the future" is a good choice to start and then we can act only after we feel enough time has passed. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CADhq2b6WwZpW_P9cNePMpxnrc1xVQwqWFhM4J0ROqUNiy%3Dh2AQ%40mail.gmail.com.