So I tried to create an external state manager for my pawnlist, and had some issues, and realized it was, frankly, silly, to generate a complete pre-existing set of pawns for players to grab if only a fraction of those pawns will ever be used.

Why am I creating an entire structure to manage a pool that, once I dole out the contents, will be worthless?

My initial concern was whether or not a list of objects instantiated in a container/owner object would be on the heap or stack.

I have to admit, reviewing the results of my code, I’m still not quite sure what’s going on, so I guess I’ll have to read up more on the internals of Python’s approach to objects and also lists.

I’m less focused on theory/internals at this point and more on getting it to work (why do I worry that this is going to come back and bite me in the ass ;))

Anyways, after realizing that I should just generate the pawn objects “on the fly” when I create the character and append them to the list.  This saves on having an extraneous manager object.  I think this idea of a ‘game state manager’ to generate a sort of total state matrix is falling on itself.  In particular, when it comes up against the objects themselves.

The other thing I dislike about my approach or how its evolving is that this OO approach actually feels like it’s limiting my genericness.  I suppose since I am making this for a specific board game, and not a generic game state manager utility for any board game, that’s ok.

I feel a little too much like things are poking into other internals.  This idea of “player owns a list of pawns” feels worrisome to me.  How will these pawn objects ultimately feedback into the player object and is this going to lead to some really horrible spaghetti mess of object relations that’s going to be hell to disentangle at a future point.

Then I think – why am I coding this at all.  I should be printing and prototyping physical things with friends, this is supposed to be a board game after all!

Then I think – because I can.  Because I want to flex my brain on a project that isn’t disentangling the mess of virtual wiring that’s my day job.  I may feel as though I’m not as productive here, but once I get the foundation up and running I feel like this may make playtesting easier, and if I can work on abstracting things out from what I’ve learned, I maybe can create a good online testing framework for my boardgames that suits my purposes.

Point being here, I guess is that I was wasting so much time trying to shoehorn things into my own wrong way of thinking instead of letting the natural flow of the code dictate what needs to be done.  Part of that is me getting used to Pythonic ways of doing things.  Part of that is me just needing a better grounding on how to approach these issues.

I’m going to try to implement this new portion of my code into my C# base and see what differences rear their little heads.
I *feel* like I should be able to do what I did with Python in a shorter time (writing it in C#) due to more familiarity with C#.

I’m still torn on how to proceed though.  I like Python and C#.  But I know I want to make it web based, so JS/HTML/CSS is important.  So I’ll still ultimately need some web framework for the UI portion which means figuring out what the best way to go is.  Does any particular framework look like it suits what I want/need/know?

I’d really like to use C#, but hate that it’s basically windows only and traps you into the framework, AFAIK.
There is F# and Fable/Elmish…  But again – I’d really have to learn something new with that.  Even thought the syntax of F# appeals to me, I’m even more at a loss w/it than I am python.
Though now that I’ve got VS Code running python properly, maybe I can get Ionide finally setup and working.  Was being difficult previously, so I just gave up.

Rust support seems to work quite fine.  GAAAAAAAAAAH too many languages not enough time, I want to know them all!

Boardgasm.Py: builtin method overriding

So – tonight I had something that looked like:

During work today, I thought why am I making a whole second method that’s just a basic wrapper around another method?  If my intuition of Python is correct I should be able to override the method, and further, that it would be fairly trivial.

So I coded the following attempt:

Do you see the issue?  Infinite recursion.
Ok, so I’m calling the append method to the list, but the append method has to call itself to add, but then.  OK, I put it aside for a bit, and when I came back to it later, it occurred to me.

There maybe a way to call the list method by calling the list class itself without instantiating it into an object.
I don’t know why this occurred to me, but I thought you know it just seems like something Python would do…

So, I modified the above code to this:

So here, on the third line, I went from self.append(player) to list.append(self, player).

Instead of calling the custom append code (self.append) , I call the original unaltered append (which was the intended behavior all along of course).

When it worked, and I double and triple checked that it actually worked, it was one of those. Well FUCK YEAH moments.

When your intuition of what SHOULD happen and what DOES happen pleasantly aligns, and not only that, the WAY it  happens is different enough so you get to LEARN something in the process.  Now that is beautiful.  And when you see HOW it did what it did and understand it, it just.

I hate to use “elegant” because it’s overused as is, and sometimes misused.  But goddamned there is something elegant about this.

The fact I was able to logically assume a certain modus operandi w/Python and see that my assumption turned out correct and further more that it matches my perception of how something would be done in the language.

I’d say that’s pretty damn Pythonic in itself.

There’s always the particularities, and an any system you’ll run across such little pleasures that make you appreciate how something is done a certain way.

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.