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
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/donald.stufft%40gmail.com
">

(original) (raw)

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