[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r19463 - trunk/subversion/tests/cmdline/svntest

From: Michael Haggerty <mhagger_at_alum.mit.edu>
Date: 2006-04-28 01:47:28 CEST

Daniel Rall wrote:
> Thanks for this and the subsequent cleanup, Michael. Garrett and I
> cooked this up yesterday, and I caught it during code review. (He
> planned to clean it up later.) I'd actually suggested that he make
> this and Skip consistent, and for both make the COND parameter to
> their constructors be polymorphic, such that COND could be either a
> function, or if not, would be treated as a boolean. Garrett and David
> James found this pretty reasonable. Sound okay to you?

I'm definitely +1 on improving the consistency. But I am very careful
about using polymorphism of this sort in Python, because Python objects
are so slippery.

First of all, you should rarely check whether an object is a function,
because usually any callable will do just as well. (Callables include
class methods, classes with __call__() methods, and several other things
in addition to functions.) One of the goals of my work in svntest was
to eliminate the special treatment of functions, but it's quite
difficult because of all of the digging around in the function object
that is being done.

The problem is that you can easy have an object that is both callable
and evaluatable as a boolean--in this case, which do you use?

One simple approach would be to have two optional parameters for each of
the decorator classes, for example

    def __init__(self, test_case, cond=1, cond_func=lambda:1): ...

    ...
        if self.cond and self.cond_func(): ...

Then either one of them could be overridden by using keyword arguments.

But I suspect that there is a better solution lurking around, maybe
involving another decorator class or two. Unfortunately it is quite
past my bedtime so I'll have to think about this tomorrow.

Michael

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 28 01:48:05 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.