>tinygrad will always be below 1000 lines. If it isn't, we will revert commits until tinygrad becomes smaller.

Love this ethos so much. Wish more projects would follow suit.

Completely disagree - limiting lines of code as an ethos makes as much sense as using lines of code written as a business metric.

What if they want to add a new feature that takes another ~1000 LoC? Can they just write it as a separate library and include it as a dependency? IMO trying to minimize LoC creates a perverse incentive to split up your package when it might not need it (in the same way maximizing LoC creates a perverse incentive to write the most verbose code possible, not necessarily the most readable/maintainable)

recuter

You say 1000 lines is an arbitrary number. Do you actually have a feature in mind that takes it above this artificial limit? Did you even read the code?

They like this round number. Fork. Why argue.

striking

It's how you get commits like these, though https://github.com/geohot/tinygrad/commit/050636bcb1068beff6...

  Subject: here's two extra lines of precious code (#307) 
  
  diff --git a/tinygrad/__init__.py b/tinygrad/__init__.py
  index 0deab3e9..31ac75d5 100644
  --- a/tinygrad/__init__.py
  +++ b/tinygrad/__init__.py
  @@ -1,3 +1 @@
  -import tinygrad.optim
  -import tinygrad.tensor
  -import tinygrad.nn
  +from tinygrad import optim, tensor, nn

There's a difference between "I will refuse features like X/Y/Z" and "I want the length of the code file to be N lines at most". The former tells you both explicitly and implicitly which features not to bother contributing. The latter is just nonsense.

recuter

This is why the good lord gave us: https://github.com/psf/black

Import line is actually improved with this commit. LGTM, ship it.

We now return to your regularly scheduled bikeshedding.