[Python-Dev] Counting collisions for the win (original) (raw)

Donald Stufft donald.stufft at gmail.com
Fri Jan 20 23:36:20 CET 2012

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 at python.org (mailto:Python-Dev at python.org) http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120120/dc1456c2/attachment.html>

More information about the Python-Dev mailing list