Hi Floris, On Fri, Aug 01, 2014 at 22:09 +0100, Floris Bruynooghe wrote: > Hi, > > On 29 July 2014 09:24, Anatoly Bubenkov <bubenk...@gmail.com> wrote: > > what do you think about extending the existing assert representation with > > this > > https://pypi.python.org/pypi/datadiff > > would be nice if we could extend datadiff with what pytest does for string > > diff > > So datadiff is not as good as comparing strings then what py.test does now? > > > and then just use datadiff for all assertions > > because for now, it's not too useful to see a comparison of 2 dicts in the > > pytest > > it's not readable > > especially if 2 dicts are big > > We should always strive to make the assertions better. If you think > they can be improved using datadiff then let's improve it. The > current reprs where simply derived from unittest2 with some > improvements from feedback later. > > > the reason why im asking without the PR is the politics about the > > dependencies > > as i know you're not so positive about adding them > > I guess new external dependencies are not ideal. But looking at > datadiff it seems to be only about 300 lines of Apache licensed code. > That's not a lot of code by any means. So I think there are a few > options which I think are realistic: > > * Vendor datadiff, I think the licenses are compatible. > > * Re-write what datadiff produces directly inside > _pytest/assertion/utils.py. It's not that a crazy task. This is only > a bad idea if datadiff keeps evolving a lot, but given it's last > commit was in 2012 I think we're fine.
That's the best option IMO. > * Have datadiff as an optional dependency, if it's importable we use > it for comparing stuff, otherwise use py.test's built in code. I > guess I'd be -0 on this one. > > There's also the option of an external plugin which was already > mentioned, but I think we should aim for the best exceptions out of > the box (which is why i'm -0 on the last option). > > > So I'm all for improving out of the box assertion reprs. The simplest > option is vendoring datadiff (maybe with a few tweaks), any objections > to that approach? The only downside I see is that the license becomes > more complicated. Isn't it maybe enough to look at the improved output and implement it? I'd ideally like to avoid licensing complications because i somewhat often get questions from companies and distributors wrt to licensing. But i agree it's not a super-big deal in this case likely. best, holger > > Regards, > Floris > > > -- > Debian GNU/Linux -- The Power of Freedom > www.debian.org | www.gnu.org | www.kernel.org > _______________________________________________ > Pytest-dev mailing list > Pytest-dev@python.org > https://mail.python.org/mailman/listinfo/pytest-dev > _______________________________________________ Pytest-dev mailing list Pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
