[Python-Dev] Counting collisions for the win

[Donald Stufft]

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>