Support dicts as Grid items and some finessing

[mikaelho]

This PR is intended more as a vehicle for discussion than something you might merge as-is (although does work as-is).

Only functionality changes are in these commits:

• Support dicts as items - Can provide dicts in the list of items given to the Grid control, i.e. works as long as the dicts have keys matching the expected columns
• Fix init call argument - Was accidentally always passing in None

Then there is a copy-paste update to tests to make them run with the new Commands.

For discussion:

• Non-functionality-impacting changes to make the code more "typical Python" and to use some of the built-in capabilities.
• Added beartype to have method name type hints checked automatically instead of manual asserts. Requirements say it is Python >= 3.6, but I saw something in docs about >= 3.9, so might need to check that before adopting, if you decide it looks useful.
• Used the black formatter on the code. Would highly recommend it to avoid any discussion and back-and-forth on styling. Also very nice to focus on the functionality and have the editor automatically reformat the code (I use darker with PyCharm, it has good instructions for other editors as well).

[FeodorFitsner]

Ha, black is on HN home page right now: https://news.ycombinator.com/item?id=30130315 :)

[mikaelho]

Ha, black is on HN home page right now: https://news.ycombinator.com/item?id=30130315 :)

👍🏻 Opinions differ, but I must say that the fundamentally non-value-adding tab discussion that immediately follows the first post there is, to me, a testament to the value of black.

But, on a more functional note, I realized the PR does not yet take care of the updates to the item values, need to add that.

[mikaelho]

Using and updating dicts as Grid item list values works now with the Grid sample.

[FeodorFitsner]

PR looks great, thank you! Working with dictionaries in Grid is definitely a must-have addition. Grid test is be a good example for other tests. Also, I'm going to reformat everything using Black in a separate branch and add it as a requirement to contributing guide.

I'm thinking... should we split Grid classes into separate files under grid directory? Having them all in grid.py is a kind of inconvenient. What does idiomatic Python say?

[mikaelho]

To my knowledge there is no idiomatic Python rule dictating how many classes there should be per file. Thus it is a matter of preference (and maybe capabilities of your editor) when a single file would be considered unwieldy and in need of being split up. grid.py is still on the smaller side and quite far from my personal threshold.

But the single file can be made much more approachable by placing the top class (Grid) first in the file, and go down in granularity as you read down the file. That is somewhat "Pythonic", as Python has no need for forward declarations in most cases.

To demonstrate, I am pushing a commit where I have just quickly rearranged the order of the classes.

[mikaelho]

Oh, and I did delve into beartype a bit more, it does support Python >= 3.7, so no concerns in that regard.

[FeodorFitsner]

Sounds great, let's merge this PR. I'm going to push https://github.com/pglet/pglet-python/pull/61 with Black formatting and annotations later this week.