This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients brian.curtin, jcea, mark.dickinson, pitrou, sbt, schlamar, serhiy.storchaka, terry.reedy, tim.golden
Date 2013-01-27.20:27:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1359318477.47.0.805246672259.issue16743@psf.upfronthosting.co.za>
In-reply-to
Content
> As Richard explained, this will not break working code, this will break only broken code

If code is both working and broken, for some reasonable meaning of 'working' and 'broken', breaking such broken code *will* break working code. I understood Richard as saying that code that 'works by dumb luck' is *also* broken.

I agree we do not need to retain unpredictable 'dumb luck' -- in future versions. But in the absence of a clear discrepancy between doc and behavior (the definition of a bug) I believe breaking such code in a bugfix release would be contrary to current policy.
History
Date User Action Args
2013-01-27 20:27:57terry.reedysetrecipients: + terry.reedy, jcea, mark.dickinson, pitrou, tim.golden, brian.curtin, schlamar, sbt, serhiy.storchaka
2013-01-27 20:27:57terry.reedysetmessageid: <1359318477.47.0.805246672259.issue16743@psf.upfronthosting.co.za>
2013-01-27 20:27:57terry.reedylinkissue16743 messages
2013-01-27 20:27:57terry.reedycreate