WIP: show meaningful changes with ruff format #314

					
				@ -410,0 +420,4 @@

				        action='store_true',

				        default=False,

				        help='Force check for missing blocker bugs after sync',

				    )

Argparser definitions are another place where visual compactness is better for human consumption than splitting the values line by line. The original file with its custom wrapping was easier to read and search in.

I don't find this style less easy to read than custom wrapping, tbh. With the custom wrapping you have to look carefully how many arguments there are per line. With this you know there's one per line. This also gives you more space for your help text before you have to deal with wrapping a string across multiple lines...

blockerbugs/controllers/api/api.py

					
				@ -96,3 +110,2 @@

				    update_data['bugs'] = [

				        {'bugid': bug.bugid,

				         'type': [tp for tp in ACCEPTED_BUGTYPES if getattr(bug, tp)]}

				        {'bugid': bug.bugid, 'type': [tp for tp in ACCEPTED_BUGTYPES if getattr(bug, tp)]}

This should probably receive the magic trailing comma for readability.

blockerbugs/util/testdata.py

					
				@ -252,0 +302,4 @@

				        date_submitted=month_old_date,

				        stable_karma=0,

				        karma=-2,

				    )

This seems like a clear regression to me. The original file as a nice flow and easy to read and parse with your eyes. Having it condensed is quite important when you want to cover all possible use cases and you need to visually see what is already covered and what it not. Splitting one of these lines arg-by-arg is a downgrade, because it breaks the pattern and prevents all the important info to fit on your screen.

In this case, it's testdata.py, a module for creating fake DB data. But the same situation will occur in testing/. You also need to specify lots of objects with lots of values, and vertical compactness of often more important in that case then individual arg values (they are often repeated over and over again anyway).

This seems like a clear regression to me. The original file as a nice flow and easy to read and parse with your eyes. Having it condensed is quite important when you want to cover all possible use cases and you need to _visually see_ what is already covered and what it not. Splitting one of these lines arg-by-arg is a downgrade, because it breaks the pattern and prevents all the important info to fit on your screen. In this case, it's `testdata.py`, a module for creating fake DB data. But the same situation will occur in `testing/`. You also need to specify lots of objects with lots of values, and vertical compactness of often more important in that case then individual arg values (they are often repeated over and over again anyway).

well, there's a few options then. If values are 'repeated over and over', that's an opportunity for improvement: could we e.g. use a functools.partial, or a wrapper for add_update, so we don't have to keep repeating those values over and over, and thus all the calls fit on one line?

well, there's a few options then. If values are 'repeated over and over', that's an opportunity for improvement: could we e.g. use a `functools.partial`, or a wrapper for `add_update`, so we don't *have* to keep repeating those values over and over, and thus all the calls fit on one line?

testing/testfunc_update_sync.py

					
				@ -49,0 +60,4 @@

				        ],

				        'updateid': 'update1_for_bug_3000',

				    }

				)

I find these changes painful. What was an a short and readable code, is now very pretty and very long code. But in unit tests, prettiness is not your primary concern. Being able to process (and test) a lot of data is.