Doing my first JUnit test thing. assertEquals(1,1,0); is failing for me. What am i doing wrong? lol

nvm, apparently some are depreciated and some take (value, value, delta) and some take (message, value, value) .... sigh

The examples I'm seeing show only 2 arguments for assertEquals, so try assertEquals(1,1). The documentation does show one example of assertEquals with 3 arguments, but the data types are double for the inputs. Maybe if you did assertEquals(1.0, 1.0, 0.0) it would pass.

Note: I don't even know how to write a Hello World in java.

Yeah think its doing weird Float comparison so add .0 or F/D or remove the third argument.

If youre comparing ints the first argument is generally a message to explain the error

I don't know how Java casting works, but there are multiple function definitions for assertEquals with 3 arguments, and none of them take integers or longs, so, your values are going to have to be cast.

What I *suspect* is happening is that it's choosing to call assertEquals(string, long, long) which turns it into assertEquals("1", 1, 0) which isn't gonna work because that's going to compare 1 and 0 and print "1" if it fails ("1" becomes the "message)

assertEquals(java.lang.String message, long expected, long actual)
Asserts that two longs are equal.

When looking through the docs, I eliminated that example you posted because I saw the first argument was a string and I didn't even read further. lol me

Naw thats not how static typing works, it'd be a compile error if it needed a string and you give it an int. Which is why I like static typing

Btw I just ran it under java 1.8 and it worked fine for me so yeah

There aren't any functions that take 3 ints, so it has to cast something, right? Does java have relaxed rules for constants vs variables, like would this fail
int i, j, k;
assertEquals(i, j, k)

Static typing, as a phrase, does not imply to me that there can't be type casting. C++ is statically typed, but will cast anything it can. To me "statically typed" means "the compiler knows what type every variable is at compile time", it doesn't mean that there won't be automatic type conversion.

It only widens primitives as far as Im aware, and widens the primitive to another primitive. String is an object so its missed by all this widening. Im not aware of Object widening, but I havent really looked at specs a lot. I guess something weird could be occurring if it were Char in one of the overloaded function definition, but I didnt look at the API to see if that was the case

Although thinking about how Print("foo" + 1) works I actually am not so confident.

Java allows some implicit casting between primitives as long as you're not losing information. The ints there could be implicitly cast to float for example.

Implicit cast to String is definitely verboten because String isnt a primitive in Java.

scala> foo1(1,1)
<console>:9: error: type mismatch;
found : Int(1)
required: String

Doesnt work in Scala at least!

So how about Print("foo" + 1)?

ETA: possibly this isn't implicit, there could be plus overloading for string, int and int, string I guess

ETA 2: if you think I know anything about Java at all, I don't, so forgive me

I think it converts "foo" to an Object, the parent type for all things java, and calls the toString method on all Objects, then does the same on 1. It can do it in that case because String and Integer are sub types of Object and have toString defined. I THINK thatd be like if it were assertEquals(Object, Object, Object)

Im mostly just guessing though, its weird stuff

I had an interview once where a guy asked me all these weird little questions, like, what would this line of python do - not normal stuff, all little gotchas and edge cases. Mostly I was like, ****, I have no idea and then he'd be like haha me neither. Oh, ok, great interview question then?

I saw one of these for javascript once - I didn't know JS but I "got" it no problem, it really stumped the **** out of (another non-JS programmer) at my job though. I can't find it now but I really liked it.

There are a few funny cases for python that I always have to remember to avoid, that annoy me because I'd prefer they weren't weird. Like..

This is a really terrible thing to do, but it would be handy to have a function where a default arg was an empty dict. Instead you usually have to say bar=None as the default and then use "bar or {}" or something like that

Keep bragging jerk!

While were on the subject mr python, can you explain to me wtf is happening here? (I know very little about lamda in python)

result =
5
5
5
5
5

Would it be clearer if I wrote it like this

res = [ (lambda: f(i)) for i in [1,2,3,4,5] ]

Which is to say, print res after it's defined and see what you get

that makes res 5 lamdas which when invoked still are all 5 I think...

Not a strong pythoner over here lol

OK so there are a few things going on. I won't drag it out even though I would in person, probably.

So, first, the statement
x = [a for a in [1,2,3,4,5]]
is going to end up with x = [1,2,3,4,5], sure. But also, after this, a will be defined, and it's value will be 5. Same as if you had done
for a in [1,2,3,4,5]: something

Second, when you say
x = lambda: foo(bar)
foo(bar) doesn't get evaluated until you actually execute the function, and then it will use the value for foo and bar that exist *now*, not when you defined the lambda.

So res = 5 lambdas that all call f(i) but they don't call it until after i=5, so you get 5 5 times

I don't know really any python but something like this is a common mistake in JS - I think each of the lambdas that are created is pointing to the same i. Each instance of the for loop, instead of creating a new block scope, is simply reusing the same scope and modifying variable i in place. So after the loop is finished, the value of i is 5 and each of the lambda is pointing to this i, which would explain the output.

That is rather cool, I could definitely see causing some bugs because of that though

So it's a little strange (and I don't know any python so I don't know if this is idiomatic at all) but this would be a correct version of that code:

I am not 100% sure what is the "expected" output of the snippet, to be honest? Do people expect
1
2
3
4
5

If so then I'd recommend
res = lambda x: f(x)
for i in [1,2,3,4,5]: res(i)

or something like that. You could do
[res(i) for i in [1,2,3,4,5]
and ignore the result also. You could also use map() but I seem to remember that you are not guaranteed ordering.

(Obviously you could do all these as one liners)

Yes, just from once overing the code. And I got it from a python dev who said he frequently forgets the behavior which implied to me he expected 12345 too