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 jack__d
Recipients Ankur.Ankan, Chris AtLee, Elena.Oat, Eric Lafontaine, Jacek.Bzdak, Puneeth.Chaganti, ankurankan, eamanu, ezio.melotti, gregory.p.smith, jack__d, levkivskyi, michael.foord, nnja, paul.moore, pitrou, rbcollins, serhiy.storchaka, steve.dower, tim.golden, trey, xtreak, zach.ware
Date 2021-07-22.21:22:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1626988941.85.0.727771435068.issue19217@roundup.psfhosted.org>
In-reply-to
Content
Hi all!

@eamanu, I went ahead and picked up where you left off. I stopped short of
opening up a PR, because I don't want to step on any toes, but I definitely
want to do what I can to give this bpo one final shove over the finish line.

Despite not creating a PR, you can see the changes here:

bpo-19217-slow-assertEq">https://github.com/python/cpython/compare/main...jdevries3133:bpo-19217-slow-assertEq

@eamanu, if you prefer, you can probably just merge this branch into
`eamanu:fix_bpo-19217`, and the conversation can move forward on GH-11204.

Also, below is a summary of what I've done:


Revert Change to difflib
========================

Link to the original thread where this change was discussed a bit:

https://github.com/python/cpython/pull/11204#discussion_r242369775

I assume this was a performance improvement. It's not clear to me why we are
not interested in this part of the diff when the input is a list or tuple.
I'm sure someone will help to explain, but this is why I reverted this change:

1. It is not an issue with unittest, and reaches beyond the scope of this bpo
2. The performance problem at the root of this bpo is solved without this
   change.
3. Reverting this change fixes most of the cascading failures throughout other
   parts of the test suite. It better constrains this fix to improving the
   implementation's performance issues while limiting changes to behavior.

Obviously, I don't have knowledge of the reasoning behind this change
sufficient to write a new bpo, but I think that this small change does deserve
its own bpo with an independent explaination of what it does and why it should
be done.

It's definitely possible that I'm missing something here, so let me know if
that's the case!


Add Regression Test
===================

The regression test basically attempts to reproduce the problem and asserts
that the code will complete within one second. It's a pretty rough approach,
but I think that it will catch a future regression. If anyone has any better
ideas, I'm all ears.


Misc
====

I also fixed the one failing test in unittest's own test case, and added a
blurb.
History
Date User Action Args
2021-07-22 21:22:21jack__dsetrecipients: + jack__d, gregory.p.smith, paul.moore, pitrou, rbcollins, tim.golden, ezio.melotti, michael.foord, zach.ware, serhiy.storchaka, Jacek.Bzdak, steve.dower, Ankur.Ankan, Elena.Oat, nnja, ankurankan, Puneeth.Chaganti, levkivskyi, Chris AtLee, trey, Eric Lafontaine, eamanu, xtreak
2021-07-22 21:22:21jack__dsetmessageid: <1626988941.85.0.727771435068.issue19217@roundup.psfhosted.org>
2021-07-22 21:22:21jack__dlinkissue19217 messages
2021-07-22 21:22:21jack__dcreate