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

Discussion in 'Python' started by kj, Aug 12, 2011.

  1. kj

    kj Guest

    *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
    kj, Aug 12, 2011
    #1
    1. Advertising

  2. kj

    Nathan Rice Guest

    <SNIP>

    public FooClass(String requiredArgument1, Long requiredArgument2, map
    yourOptionalArgumentMap) {
    ...
    }
    Nathan Rice, Aug 12, 2011
    #2
    1. Advertising

  3. kj

    MRAB Guest

    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 )
    MRAB, Aug 12, 2011
    #3
  4. kj <> writes:

    [...]
    > def quant(xs, nlevels=MAXN, xlim=MAXX):

    [...]
    > My Java implementation of it already requires at least 8 method
    > definitions, with signatures:


    (BTW, your approach won't work if several optionals have the same type.)
    [...]

    - use Integer, Float, etc. everywhere. The compiler will box primitive
    types as needed at call sites
    - re. default values (on positional params), use null to indicate a use
    of the default, or use ellipsis, or use class-provided static fields
    at call sites, or use a special class to represent all the optional
    parameters
    - re. named parameters with default, use a map, or change the call sites
    to remove them

    -- Alain.
    Alain Ketterlin, Aug 12, 2011
    #4
  5. kj

    Miki Tebeka Guest

    You can probably do that with varargs.
    Miki Tebeka, Aug 12, 2011
    #5
  6. On Fri, Aug 12, 2011 at 6:02 PM, kj <> wrote:
    > I ask myself, how does the journeyman Python programmer cope with
    > such nonsense?
    >


    Firstly, figure out how many combinations of optional arguments
    actually make sense. Any that don't, don't support. That may well cut
    it down significantly. And then, if there are any that make sense but
    will be really rare (eg if you allow optional specification of a max
    and a min, and most times you'll use either both bounds or neither),
    you can save a few by having the "optional" argument specified with a
    sentinel meaning "default". It's ugly in a few places to justify
    simplicity in most.

    If you really need 100% flexibility, then the suggestions already
    posted will definitely be the best.

    ChrisA
    Chris Angelico, Aug 12, 2011
    #6
  7. On Fri, 12 Aug 2011 17:02:38 +0000 (UTC), kj <>
    declaimed the following in gmane.comp.python.general:
    >
    > 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.
    >

    Does this apply?

    http://download.oracle.com/javase/1,5.0/docs/guide/language/varargs.html

    --
    Wulfraed Dennis Lee Bieber AF6VN
    HTTP://wlfraed.home.netcom.com/
    Dennis Lee Bieber, Aug 13, 2011
    #7
  8. kj

    rav Guest

    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.
    rav, Aug 13, 2011
    #8
  9. kj

    Dirk Olmes Guest

    On Fri, 12 Aug 2011 17:02:38 +0000, 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.)


    Can't you sidestep the porting effort and try to run everything in Jython
    on the JVM?

    -dirk (Python lurker with Java experience)
    Dirk Olmes, Aug 15, 2011
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. yop

    PopUp Message aka Msgbox

    yop, Aug 26, 2003, in forum: ASP .Net
    Replies:
    7
    Views:
    1,587
  2. Manuel
    Replies:
    1
    Views:
    398
    =?Utf-8?B?UGhpbGxpcCBXaWxsaWFtcw==?=
    Oct 13, 2005
  3. JamesMason
    Replies:
    5
    Views:
    1,774
    William Tores
    Jul 24, 2004
  4. Bryan Galvin
    Replies:
    2
    Views:
    425
    Bryan Galvin
    Sep 29, 2004
  5. opalpa  http://opalpa.info
    Replies:
    0
    Views:
    365
    opalpa http://opalpa.info
    Oct 30, 2006
Loading...

Share This Page