Commas between pairs of {}s and the whole list in one pair of []s.

example:
[
{ "id" : "1",
"name" : "Zephyr",
"phone" : "1211"
} ,
{ "id" : "117",
"name" : "Tamara",
"phone" : "5708"
}
]

Thanks, now to work on putting this in the game.

Keep in mind you can put the info into a (csv or whatever) table and then convert it to json to use in the game. You don't need to actually type every brace and comma.

Actually, I created a script to rip the data from the python file and into the .json:

import json
key = 999
while True:
____key = key+1
____try:
________item=verify_equip(key, False)
____except KeyError:
_________pass
____else:
________f = open("shop.json", "a")
________f.write((json.dumps(item, default=lambda o: o.__dict__))+",\n")
________f.close()

I put this at the bottom of 'shop.py' which did contain all the item data. Starting at 1000 (the lowest iD), it converts the object to json using the now defunct 'verify_equip' and writes it to the file.

One other thing, the json file is divided up into sections for each item. They are labelled 0,1,2,etc... Is there any way to change these to fit the iD of the item or are they fixed? It would be a lot better if they fitted the iD's as I don't know how many items there will be (hence the iDs which allow 999 of each type).

This is probably just how your IDE displays lists? It's not ID, just position in array.

You really shouldn't maintain separate names simply for the sake of formatting. Instead, write a formatter and use it.

def indef(s):
____letters_an = 'aeio'
____if s[0].lower() in letters_an:
________return 'an ' + s
____else:
________return 'a ' + s

Then you drop indef(s) where you need.

"his fists" is also suboptimal, what if you have a female combatant, a genderless humanoid such as a golem, or a group (mob of peasants)?
Make a weapon class. Fists would be an instance of the class. Then, when you're assembling the attack message (in battle), get the pronoun and use it in a string.

I was in the same spot once and this helped: https://wiki.python.org/moin/PythonSpeed/PerformanceTips . I still sometimes feel I'm not making full use of pythonic abilities when I get into more complex bits of code, but hey, Rome wasn't built in a day.

Moar:

You probably want three layers in your application:

1. Content / media. Text content goes into text files, other resources go into a folder as-is.
+ a json that translates resource names to resource file locations, e.g. "dragon_roar" : "sfx/dragon.ogg"
Numbers, artistic text, and other fluff all live here.

2. The engine. The brains of your game, the object instances and the control flow. Unless you want to make a hardcore pseudocode parser, the core entity classes of your game live here. (To easily save the game during pre-alpha and alpha, serialize the shit out of it with pickle or something like that.)
For example, in combat, an attack that deals plasma damage to targets in a 20-ft radius is assigned to a monster in the monsters roster json in Content, and what plasma damage is is described in pseudocode in yet another json in Content, so the engine doesn't know what plasma is. But it does know what a combat action is, so it takes a list of target objects (combatants), applies modifications to their fields as described in the attack spec in Content, puts any effects into the priority queue (storm dragon gets regeneration, curtain catches fire), then processes the priority queue and proceeds to the next action.
This produces dictionaries of strings at each step.

3. The interface. This takes dictionaries and communicates their content to the player. If you're doing a pure stream of text, this is where string formatting happens: it takes [{"type":"attack", "attacker":"orc bandit #3", "weapon":"sword", "target":"you", "damage":"10"}] and prints Orc bandit # 3 attacks you with his sword and deals 10 damage. Anotehr version of the interface can run on Qt or kivy or django or a graphical application: you feed the exact same dictionary to the interface, but instead of sticking the dictionary in an English sentence, it swings the orc bandit icon in the direction of the player icon, makes a red 10 pop up above the player icon, and plays ouch.ogg.

I've actually, for a long time, been thinking of doing something similar. My idea would be a Wizardry-like dungeon crawler (party of adventurers, turn based non-tactical combat), but with mechanics borrowed from SaGa and the Elder Scrolls (thinks like stat growth mechanics and spellmaking, for example).

The problem is actually getting myself to actually do this.

I am of the opinion that, assuming your code isn't pathologically bad, that either:
1. You don't need your code to be super efficient; it being slow will likely not be an issue.
2. A simple change of algorithm will put the code into category 1, or
3. Python is not fast enough and you should write that part of the program in a faster language like C or Rust. (Fortunately, there are ways to call C code from Python (and Rust can easily pretend to be C for this purpose).) Just be aware that those languages are harder to code in, and C is notorious for undefined behavior (Rust fixes that, at the expense of giving you lots of compiler errors instead).

Thank you all for your help and ideas.
Yes that makes sense, no problem though I'll replace 'iD' with 'type' to distinguish between the weapons/helmets/etc.
This has been on the list of issues for a while now, I just haven't got round to fixing it yet. :D
As you say, speed shouldn't be much of an issue, however, efficient code makes it easier to work with and also makes the file smaller (Which is important when I freeze to .exe because the size increases a lot).
This is surprisingly similar to what there is already:

1. Inside the data folder is the icon, the save files (Although they are likely to move to a folder called saves), the new jsons for items, and an empty folder where the sound FX were stored.

2. Various modules for data handling containing lots of subroutines.

3. The main script for the game which calls on these subroutines.

The exception is that both the battle engine and the shop are embedded in the main script as well.

Code that is efficient in terms of CPU resources is not necessarily efficient in terms of memory usage or code size. In other words, there is a trade-off to be made here.

There's also the issue of maintainability; If you can't understand the code you wrote, you will have difficulty changing it if you need to later (for example, to fix a bug or you decided to change some aspect of your game design). This is one respect in which Python is typically considered better than C. (In particular, there's the wholce CPU time versus programmer time trade-off going on here.)

Also, if I understand how the whole freeze to .exe thing works (I have never used it, probably because I only use Linux), the extra size is mostly due to the interpreter and standard library; doubling the size of your code won't double the size of the resulting .exe. (You also see this in languages like C, though it's not as apparent for dynamically linked .exe files (which are the most common type these days) as for statically linked ones.)

Try putting the battle engine and shop into separate modules; there's no reason for them to be in the main .py file. Also, it's unlikely that the battle engine and shop would need each other to function, and this makes it easier to make sure they don't accidentally become coupled.

Also, having them be in separate modules makes it easier to test them separately.

Usually there is this workflow advised:
1. Make clean code. Clean means readable, maintainable and without antipatterns.
2. Run it. Everything runs as it should.
3. Check performance. Is it slow? If not, no problem. You have perfectly fine code which you will able to maintain just fine.
4. If the performance is bad, then you optimize. Optimizing for speed (not to mention executable size, which is probably not done today in PC environment) is dirty, messy stuff which will usually make the code ugly and hard to maintain.

So clean code should be your first priority, especially as a beginner. For text game, I don't think you will need to optimize. Don't worry about speed. Especially don't worry about python executable size. Your code will be the smallest part of it. You see, you need to include whole Python environment with your program, so users can run it without Python installed on their computer. That is around 20mb. I don't think your text game will reach that soon.

Yes looking at the numbers I see what you mean, the application and other modules are about 1.4mb, total size 15.3, so code is about 9% of it.

I have to agree with dtgreene and Nightblair on this one, you really should not be thinking too much about optimizing if you're happy with the execution speed of your code - and in this particular case (a text-based RPG), I don't think you'll have any issues.

The article I shared is still a nice read though, and some of the stuff mentioned there will sometimes get you that extra speed boost you might want to get out of your code. Even the author mentions you need not over-optimize, since this generally ends up wasting your time on too little gain.

I also recommend browsing through the famous PEP 8, especially if you're working in a multi-developer project and want to ensure your code doesn't make others cringe :).

Good luck with everything!

Having less import statements in your code is probably the best way to approach things if you want a small frozen executable size, but of course, that isn't always possible. Still, we're living in the terabyte age, nobody will care if it's 2MBs or 20MBs... unless you want to distribute it on floppy disks :).

Unless you're writing code intended for a microcontroller (like an Arduino), but in that case, why are you writing in Python anyway? (For microcontrollers, C is the dominant language, with C++ used sometimes (but you have to be careful), and Rust being an emerging possibility.

(Of course, for conventional computers, Python is going to be good enough for your needs, and it's easier to write and debug, anyway.)