On Aug 12, 1:35 pm, MRAB wrote:
> On 12/08/2011 18:02, kj wrote:
>
>
>
>
>
>
>
>
>
> > *Please* forgive me for asking a Java question in a Python forum.
> > My only excuse for this no-no is that a Python forum is more likely
> > than a Java one to have among its readers those who have had to
> > deal with the same problems I'm wrestling with.
>
> > Due to my job, I have to port some Python code to Java, and write
> > tests for the ported code. (Yes, I've considered finding myself
> > another job, but this is not an option in the immediate future.)
>
> > What's giving me the hardest time is that the original Python code
> > uses a lot of functions with optional arguments (as is natural to
> > do in Python).
>
> > As far as I can tell (admittedly I'm no Java expert, and have not
> > programmed in it since 2001), to implement a Java method with n
> > optional arguments, one needs at least 2**n method definitions.
> > Even if all but one of these definitions are simple wrappers that
> > call the one that does all the work, it's still a lot of code to
> > wade through, for nothing.
>
> > That's bad enough, but even worse is writing the unit tests for
> > the resulting mountain of fluffCode. I find myself writing test
> > classes whose constructors also require 2**n definitions, one for
> > each form of the function to be tested...
>
> > I ask myself, how does the journeyman Python programmer cope with
> > such nonsense?
>
> > For the sake of concreteness, consider the following run-of-the-mill
> > Python function of 3 arguments (the first argument, xs, is expected
> > to be either a float or a sequence of floats; the second and third
> > arguments, an int and a float, are optional):
>
> > def quant(xs, nlevels=MAXN, xlim=MAXX):
> > if not hasattr(xs, '__iter__'):
> > return spam((xs,), n, xlim)[0]
>
> > if _bad_quant_args(xs, nlevels, xlim):
> > raise TypeError("invalid arguments")
>
> > retval = []
> > for x in xs:
> > # ...
> > # elaborate acrobatics that set y
> > # ...
> > retval.append(y)
>
> > return retval
>
> > My Java implementation of it already requires at least 8 method
> > definitions, with signatures:
>
> [snip]
>
> I would declare:
>
> short[] quant (float[], int , float)
> short quant (Float , Integer, Float)
>
> and see how it goes.
>
> "float" and "int" should be boxed to "Float" and "Integer"
> automatically.
>
> If the second and third arguments are frequently the default, then I
> would also declare:
>
> short[] quant (float[])
> short quant (Float )
This seems to be a very good solution but I would replace basic types
with wrappers
short[] quant (float[], Integer, Float)
short quant (Float , Integer, Float)
When you implement those two methods (where you need to check if
Integer, Float are not null) then you can define two more methods:
short[] quant (float[]) {
return quant (float[], null, null);
}
short quant (float) {
return quant (float, null, null);
}
That gives you 2 methods for unit testing.
--
http://mail.python.org/mailman/listinfo/python-list
