brut-ish force...

If performance is a concern, it's still better to write the 'yield' expression. These are lazy gens and they're sometimes half as slow, but it's likely just splitting hairs unless you're working on exceptionally large sets of data.

Actually, generally accepted best practice is to not use named lambdas. Lambdas should be 'throw away' expressions, not statements and def fn's will usually eek out performance over λ expressions but not by anything really noticeable unless you have some order of op stuff going on. If you really want to make this fn sing, use a generator, ala my fork.

using a lambda, an "anonymous function" to make a named function is sooOoOOoOOooOooOooOo smart and definitely not bad practices. Most linters will yell at you for this.

While the tests might only provide a singular entry, the datatypes in use don't actually restric the number of entries which suggests the intent of the code is to also support multiple entries, so I think the min would be important, but ultimately, I didn't write the original stuff. Regardless, if there should only ever be one entry, then the code should only provide datatypes and paths that allow for a single entry, otherwise, it should be 'defensive'.

I think you are right, we don't need min or the function f
we only need the truck's last snapshot
I updated my sol accordinagly

In find_furthest_west(), why is the min required in

f = lambda v: min([x['position'].x for x in v])

As I understand the script, x is only one value as f(data[a]) returns the entries at element a.

Thanks in advance.

Cool quotes

Hi; I just solved this and I must agree that it was quite frustrating to debug as the output/display of wrong results is not very clear.

Also, you are clearly on the right track - your recursive logic is correct but your base case is where things are going wrong I think.

Using your code, you are failing 3 of the fixed tests - however, none of these correspond to the trees that you have drawn above though (so I'm not sure how you managed to obtain that drawing).

For example, of the 3 test cases where your code is failing, the first one actually is testing the following pair of trees a,b:

# tree a              tree b
    3                    3
  /  \                  / \
 1    1                1   2

and the expected answer is False for this input pair.

Hopefully that helps you debug a bit better (I can't share with you more of the test cases because otherwise people could just hardcode the correct answer, as there are no random tests).

In Python 3.10, I'm failing a depth 2 test: Should return false for non-equal trees.

I've verified that my code returns false, but the test fails with 'True should equal False'

The tree structure is

 3       4
|  \     |  \
1   1    1   1
| \ |\   | \ |\
()()()() ()()()()

Am I missing something?

Update: I've hard-wired the code to check for this tree, verified the branch with prints statements in the log, but the test fails regardless of whether I return True or False

Short code isn't 'good code' if it's several orders of magnitude slower at the end of the day.