I'm learning Python through attempting a reasonable sized project and I've got another Python question, this time about data structures. I've got a problem I'd usually solve in C with a 2D array of structs, and I'm uncertain as to what's the best Pythony approach to the same problem. In my current simulation/game I need to represent a 2D world of tiles with properties. In C I'd implement a 2D array of structs that contain the properties I need (or more likely a 1D array of structs that acts like a 2D array with offsets, but I'm splitting hairs here). But as far as I know Python doesn't have a direct analogue to the array of structs that C has (please correct me if I'm wrong). Instead I've got lists, tuples, dictionaries and class objects to play with instead. I don't know the exact specifics of the dimension I need, as this is all very experimental and I'm making things up as I go. The array will most likely be fairly large: probably about 200 by 200, maybe more. The number of properties I need per tile is unknown but is going to change as I add more stuff into the simulation, however it is unlikely to ever be more than ten. I could go with a class instead of a struct, but my understanding is that Python uses dictionaries for its classes, and that doesn't sound that efficient for a large 2D array. My gut feeling from my experiences with functional languages is to go with a tuple as a struct, and wrap these around with a whole bunch of helper functions within a package for data access. However my scanning of message boards suggest that most Python devs think of tuples as immutable lists (which they are), and I will be changing the information contained within them here. The helper functions can work around this, but I'm unclear as to whether I'm breaking good Python practice by using tuples in this way. Alternatively, I could just store each property in a list that acts like an array. That's probably less awkward for data access, but it goes against keeping all properties of a tile tied up in a single unit. I'm unsure as to which method is the best way to solve this problem, or if there's another better way I haven't thought of. Any suggestions on how you'd try to solve this problem in Python? Thanks in advance.

I wouldn't worry about it, especially if it's only going to be 200x200. Just use what seems most natural and optimize later if the profiler tells you its a problem.

I'm worried about my "natural" instincts being not the most "Pythony" ones. I'm pretty entrenched in C style data structures, and I know that they often aren't the best approach when using a new language. I'm still getting used to using lists as the basis of iterators rather than using indices for example.

I suppose that since the whole purpose of this is a learning exercise for Python I could just go with the tuple approach and see how well it works - I'm planning on rewriting whole chunks of this as I make mistakes anyway.

Ok. Scratch natural, and replace with easiest.

Quote:Original post by Trapper Zoid
My gut feeling from my experiences with functional languages is to go with a tuple as a struct, and wrap these around with a whole bunch of helper functions within a package for data access.

Function calls in Python are rather expensive, so that may actually be slower than using classes.

I'm not python expert myself but few things popped in to my mind while reading your post as i'm still learning python too.

Quote:Original post by Trapper Zoid
I could go with a class instead of a struct, but my understanding is that Python uses dictionaries for its classes, and that doesn't sound that efficient for a large 2D array.

I thought that python "structs" as described in manual are just classes without specific defination. Eg. whenever you instantiate such struct it will still create class instances without attributes so you're not getting more or less by using them. Second thing is that what are you meaning with that python uses dictionaries for classes? If its the internal usage i wouldnt really worry about that being the bottleneck, and you cant get without class descriptors and lookups in any OO capable language?

And next thing is ofcourse, whether or not it is fast enough you'll get to know as soon you do something like it, thats the beuty of python, fast prototyping. And there's thing like psyco to try if it gets too slow.

You're all most likely right - I should stick to using classes until I see a reason to otherwise. I suppose I'm baulking at using hash tables for structs as it seems wasteful from a C perspective, but it probably makes no difference for a Python prototype.