So I started to work on a python version of the little code I had in C#. I ended up making a simple player class. I learned the “extend” method of the List class.
I was testing my list of players by doing Playerlist.append(p1)
But I tried to append a list Playerlist.append(p2, p3)
No dice. Looking up info I found that since append appends as a single object I’m not appending the 2 player objects, only appending a list as a single unitary object I imagine if one were to view diagrammatically visually it may look something like [p1, [p2, p3]] 2 object list, player object and list object as opposed to [p1, p2, p3] 3 object list, 3 individual player objects.
So learned about the “extend” method to append an actual list to a list (I’m sure it’s deeper than that, but that’s the basic use I had for it).
The fact that Python is so vastly different to C# and I’d have to learn a lot of the particularities may mean that I may not want to do it.
On the other hand, I coded a lot of what I wanted in a shorter time and in less code than it took for C#.
Then again, I had already done the hard work w/C# to figure out the basic situation.
Perhaps, the next test would be the inverse – write in Python (this time the code for dealing with Pawns and ownership of pawns and their location in the playspace), and write the C# code after the Python. I could see if writing in Python helped the C# go quicker.
Most of the issue is that my intuition of some things in Python don’t quite fit the actual model it provides. And that’s fine, that’s just how Python is (or any language) and you’ll always be having to rethink such things, whether it’s a programming language or a specific library. You’re never going to know all models 100% exactly. That’s why they’re models. And those models/frameworks you’re working with, may have underlying patterns that act as a common language of understanding or it may be that those models are, themselves, common languages between classes of thinking/operating.