I believe that either solution has the potential to break existing applications so to ensure that no applications are broken there will need to be a method of disabling it. I also believe that to maintain the backwards compatibility that Python has traditionally had in bug fix releases that either solution will need to default to off. Given those 2 things that I believe, I don't think that the argument should be which solution will break less, because I believe both will need to be off by default, but which solution more adequately solves the underlying problem. On Friday, January 20, 2012 at 5:11 PM, Terry Reedy wrote:
On 1/20/2012 2:51 PM, Donald Stufft wrote:
I think the counting collision is at best a bandaid and not a proper fix stemmed from a desire to not break existing applications on a bugfix release ...
My opinion of counting is better than yours, but even conceding the theoretical, purity argument, our release process is practical as well. There have been a few occasions when fixes to bugs in our code have been delayed from a bugfix release to the next feature release -- because the fix would break too much code depending on the bug.
Some years ago there was a proposal that we should deliberately tweak hash() to break 'buggy' code that depended on it not changing. This never happened. So it has been left de facto constant, to the extent it is, for some years.
-- Terry Jan Reedy
_______________________________________________ Python-Dev mailing list Python-Dev@python.org (mailto:Python-Dev@python.org) http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com