[py-dev] Advanced assert equal

[Floris Bruynooghe]

Hello

On Mon, Sep 06, 2010 at 10:33:53AM +0200, holger krekel wrote:
> On Sun, Sep 05, 2010 at 22:42 +0100, Floris Bruynooghe wrote:
> > On Thu, Sep 02, 2010 at 11:27:22AM +0200, holger krekel wrote:
> > > On Mon, Aug 16, 2010 at 14:51 +0100, Floris Bruynooghe wrote:
> > > Hum, couldn't custom representations just mean that there is no 
> > > "history" of where the object comes from? 
[...]
> > Not sure what you're referring too with the "history" comment.  If you
> > mean that as soon as a specialised hook is found the previous
> > explanations (e.g. from Assert AST node) get lost I'd like to
> > disagree.  It seems reasonable for the new hooks to just provide a
> > more detailed/specialised explanation of a particular part of the
> > failure rather then replace the entire explanation.  Otherwise you
> > might also lose detail.
> 
> Hum, ok.  Let's see how this plays out with real failures.

Agreed, I don't feel too strongly about it but would like to see how
it works out as it is now.

> > To me it seems more logical to add a separate hook for each .visit_*()
> > method rather then put multiple together.  But maybe that seems
> > artificial from a user point of view?
> 
> I guess I prefer "pytest_assert_binop(op, val1, val2)" 
> but keeping strictly to the visit relation also has merits. 
> I guess my preference also comes from trying to avoid introducing
> too many hooks. 

Again I don't feel too strongly, you've got more say on the hook API
then me so if you want I can rename it and we can see how it looks
once there are more implementations for e.g. "in", "is" etc.


> > If you like this version I can create a fork on bitbucket and start
> > working on more/better hook implementations.
> 
> Great, please do so.  Two review notes regarding your patch already: 
> 
> * please try to avoid global imports in plugins, rather only import 
>   e.g. difflib/pprint where you actually use it.  This is to try to 
>   keep interactive startup-time minimal, particularly wrt builtin plugins. 
> 
> * i suggest to put tests to testing/plugin/test_pytest_assertion.py 
>   (rather than testing/code/...) especially since the tested functionality
>   is contained in the pytest_assertion.py plugin.  For direct unit tests
>   you may also directly do "from py._plugin.pytest_assertion import XYZ". 

As you've probably noticed I've made a fork at
http://bitbucket.org/flub/py-trunk-assert.  I've addressed these two
points in it already, or so I hope.  I can't figure out how to
properly test the plugin however, it either feels too brittle or too
loose.  So any hints on how to test that sort of thing would be
welcome.

Other then that I need to get on with implementing more and better
default behaviour, at least cover everything unittest2 does.


Floris

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org