On Aug 12, 1:35 pm, MRAB <pyt...@mrabarnett.plus.com> 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