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

Jeffrey Gaynor jgaynor at ncsa.uiuc.edu
Fri Aug 12 13:24:27 EDT 2011


One Java-eque  solution is to pass in an object that has the arguments and build the validity logic into that object.

So you have

public class LimitsAndLevels{
 float[] whatever = null;
 float anotherOne = 0.0; // or maybe some other overloaded value

  public float[] getWhatever(){
     isValid();
    return whatever; 
  }
  public boolean hasWhatever(){
     isValid();
     return whatever != null;
  }

  public void isValid(){
       // Code to check validity
       // Probably throws an IllegalArgumentException if you need.
       // That exception extends RuntimeException, so no need to put in a throws list
  }
}



Then you pass this, e.g., 

public class HeavyLifter{
  public int[] quant(LimitsAndLevels args){
    // acrobatics.

  }
}

Hope this helps...

Jeff


----- Original Message -----
From: "kj" <no.email at please.post>
To: python-list at python.org
Sent: Friday, August 12, 2011 12:02:38 PM
Subject: Java is killing me! (AKA: Java for Pythonheads?)




*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
INSANE.

Some advice on implementing and testing functions with optional
arguments in Java would be appreciated.

TIA!

kj
-- 
http://mail.python.org/mailman/listinfo/python-list




More information about the Python-list mailing list