I see the advantage of the inline lambdas, but also it seems like it would hamper the ability to test the functions which can often have intricacies that catch you out. I believe one of the principles of Tinygrad is that tests shouldn't be part of the core codebase and shouldn't add to the total linecount.

I think there is an opportunity there to have a tag in comments for tests.

Have a hotkey to generate an id so you could have

  # lift x+y out of reduce on lt               :testID: color_adjective_noun  
  ((UPat.var("x")+UPat.var("y")).or_casted() < UPat.var("c"), lambda x,y,c: (x < (c.cast(y.dtype)-y)) if no_range(y) and no_range(c) else None),

and it creates a test that exists away from the main codebase. A process that runs tests could scan the code for testID's, intelligently extract the relevant part of the code into the test harness and runs the tests. There would need to be some infrastructure needed to handle placing the code to be tested into the right context but you could have

  1. A codebase that contained no active code required simply to facilitate tests, 

  2. All test tags auto removable for distribution builds

I agree. It is definitely readable but clearly formatting decisions were made to keep line count down over the flow of code. It isn't even just the variable names, things like having a function with a single return statement on one line, while legal, I cannot imagine why someone would do it in a non one off script code.