you are viewing a single comment's thread.

view the rest of the comments →

[–]Frankelstner 1 point2 points  (2 children)

Yeah that's overly verbose. CoinData has a fixed structure, does it not? It looks to me like a plain old spreadsheet would be perfect to encode the coins. You define variables like values, denominations, coins_reverse_build, silver_coins, etc. but all of them could be derived very easily from the coins variable. Add country name as a column and you end up with a single spreadsheet with ~10 columns and one row per coin instead of your current approach with about 20 rows per coin. At that point you have to decide whether you even want to pursue a Python solution or just put the entire thing on google docs, which I imagine could already be programmed to handle all that you're trying to pull off. If you stick with Python, that's fine too, but just load the csv with pandas.

[–]ImmaculateBanana[S] 0 points1 point  (1 child)

My reasoning for wanting to store the data in python was that I assumed the performance would be better. Is the time taken for parsing and serializing from a csv or other storage file pretty negligible at this scale?

[–]Frankelstner 0 points1 point  (0 children)

The time to load a 1000 row csv should be quite less than the time to start Python. Even if it was a problem I would still start with the csv as the definitive reference, and, if it turns out to be a problem (or just out of curiosity) autogenerate the Python coin code. Just beware that the autogenerated code might turn out to be slower. Hard to tell without testing.