Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Java is killing me! (AKA: Java for Pythonheads?)

Reply
Thread Tools

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

 
 
kj
Guest
Posts: n/a
 
      08-12-2011



*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
 
Reply With Quote
 
 
 
 
Nathan Rice
Guest
Posts: n/a
 
      08-12-2011
<SNIP>

public FooClass(String requiredArgument1, Long requiredArgument2, map
yourOptionalArgumentMap) {
...
}
 
Reply With Quote
 
 
 
 
MRAB
Guest
Posts: n/a
 
      08-12-2011
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 )
 
Reply With Quote
 
Alain Ketterlin
Guest
Posts: n/a
 
      08-12-2011
kj <(E-Mail Removed)> 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.
 
Reply With Quote
 
Miki Tebeka
Guest
Posts: n/a
 
      08-12-2011
You can probably do that with varargs.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      08-12-2011
On Fri, Aug 12, 2011 at 6:02 PM, kj <(E-Mail Removed)> 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
 
Reply With Quote
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      08-13-2011
On Fri, 12 Aug 2011 17:02:38 +0000 (UTC), kj <(E-Mail Removed)>
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,...e/varargs.html

--
Wulfraed Dennis Lee Bieber AF6VN
http://www.velocityreviews.com/forums/(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
rav
Guest
Posts: n/a
 
      08-13-2011
On Aug 12, 1:35*pm, MRAB <(E-Mail Removed)> 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.
 
Reply With Quote
 
Dirk Olmes
Guest
Posts: n/a
 
      08-15-2011
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)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Killing The "Double Download" Box--Need Help Please Ducati@Darmah.net Firefox 2 05-05-2005 12:29 AM
Killing NAT translations. AM Cisco 3 02-03-2005 11:43 PM
Killing processes in CatOS Arnold Nipper Cisco 0 01-12-2005 05:33 PM
killing a lingering VPN connection Eric Sabine Cisco 0 06-03-2004 03:04 PM
Killing java jobs Roedy Green Java 1 04-12-2004 03:31 AM



Advertisments