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 > >
_______________________________________________ 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/archive%40mail-archive.com
