You need some third party apps to make a standalone app out of Python. Plus it has many many add-ins built with C, C++ and whatever your programming weapon of choice. It can be a mashup of binary vomitus that can have some serious consequences. I saw one today.
This particular Python app was built by some troglodyte who's previous arena of expertise was DBase and FoxPro and thought that relational databases were a passing fad. So this app that he built fed itself data using .dbf files. Let me tell you, finding a .dbf file converter for free is like trying to find someone with a full set of teeth in a small southern town. Excel stopped outputting .dbf with 2007. Why would you need a dbf converter when you could use something more in the 19th century like a csv file? (Twentieth century is xml and 21rst century is JSON).
Well, it all has to do with the Perils of Python. The importer in this case was written in Python, and theoretically, it could import both csv and dbf files. CSV files always failed. But they didn't fail consistently. Sometimes the python input parser would correctly import a CSV and then on another like file, it would create extra fields, columns or whatever dinosaurs called table columns. It was a huge WTF? moment.
Then it came to me in a flash while I was emptying my colon. It was the colon in the date field. In some random cases, it correctly surmised that it was just another character in the field, and when another file was read in, it immediately said "AHA! Reserved character separator!. So why the inconsistent behavior? Da Python!
The input parser would make a decision on which import method to pass the input to. Depending on file size, it went to a method that was a layer of abstraction over the Python engine, or virtual machine, or Model T or whatever they call Python binaries. This would cause a choke. With just a few changes in the file characteristics, it would get imported natively and happily work. Unfortunately, you couldn't predict when and where it would work.
SO .... people beware of hiring the guy next door who will do the job for cheap ... these guys who still program with tools from the middle ages are doing you more harm than good. And your program is only good when it is operating on their development machine. Put it out in the real world and it fails quicker than the zipper coming down on Pee Wee Herman's and Fred Willard's pants in a darkened theater. Caveat emptor. The price you pay for using Python is huge if you want real inter-connectivity.