Java is killing me! (AKA: Java for Pythonheads?)

Dan Stromberg drsalists at
Sat Aug 13 00:12:29 CEST 2011

Check varargs (as another poster mentioned), and consider doing your unit
tests in Jython.  Some shops that don't want Python for production code are
fine with Python for unit tests.

However, if the reason for preferring java is type checking, you could
perhaps get somewhere by suggesting pylint.

On Fri, Aug 12, 2011 at 10:02 AM, kj < at> 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:
>    short[] quant (float[], int    , float)
>    short[] quant (float[], int           )
>    short[] quant (float[],          float)
>    short[] quant (float[]                )
>    short   quant (float  , int    , float)
>    short   quant (float  , int           )
>    short   quant (float  ,          float)
>    short   quant (float                  )
> Actually, for additional reasons, too arcane to go into, I also
> need four more:
>    short   quant (Float  , Integer, Float)
>    short   quant (Float  , Integer       )
>    short   quant (Float  ,          Float)
>    short   quant (Float                  )
> Writing JUnit tests for these methods is literally driving me
> Some advice on implementing and testing functions with optional
> arguments in Java would be appreciated.
> TIA!
> kj
> --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Python-list mailing list