Wot no Python Executable?

So how did my first foray into Python go? 

Well partly I cheated and wrote Iron Python code in Visual Studio – so obviously I write a lot of .NET code but using Python syntax. The idea was to get a running start on how to structure my Python and I wrote a bunch of classes with methods, adopting the MVC pattern to push that beyond where I would normally go. So far, I am still enthusiastic about the language. There are odd puzzles to do with variable scope but I am confident those will work out nicely as I write more code. The short and snappy syntax bodes well for productivity although debugging minor spelling mistakes (character case and all that) counteracts that a bit.

You might think that building a .NET Python app was a quick route to having something I could distribute as an executable to others but (and this is a big BUT) – it is possible to encapsulate an Iron Python program as an executable but it is a big hill to climb.

This post covers the general Python app distribution problem domain way better than I can.

Python looks like a programming language for YOU to use but the infrastructure lacks more than a little when it comes to sharing. A given program can (perhaps must) be built on a plethora of pre-existing libraries that may not be apparent to your neighbour when it comes to sharing. Worse for me ‘cos I generally think command line programs stink (and I do understand why you might think otherwise) – perhaps I had better try and explain where I am coming from. Some (or maybe all) of it is a history.

My first programs were COBOL encoded in EBCDIC and punched onto 80 column cards. These cards were fed into a card reader’s “hopper”, compiled and (if all went well) the program ran. The program caused other punched cards containing data to be read and the resulting output was printed (astonishingly quickly by today’s standards) on a line printer – or just possibly output as newly punched cards ready for another process. If I got my program and data into the computer room “in-tray” by 17:00 I usually got the output the following day. The ultimate “command line”.

Then I started in a new job and was assigned to try out something called BASIC on a DEC PDP 11/70 as this was a platform that was seen as suitable for “end user” computing and someone was needed to be able to help out with development work within various departments of the business. I was handed the language specification for DEC’s Basic+ and left to my own devices for a bit. It was a pivotal moment because BASIC contains two very important keywords – INPUT and PRINT. I realised that my future programs could interact with the user while they were running. The other “tools” were a bit primitive – VT52VDUs and printer terminals  hooked up to the computer room via 300 baud modems. Clunky kit but the software (in comparison to what had gone before) could soar.

At about the same time the Apple ll and Commodore PET micro computers were also introducing a new and interactive model to a wider audience (here too BASIC was a key component). A common anti-pattern of that era was to get the user to type in some data, validate it and then display the result. The “anti” bit came when the validation failed – typically this resulted in user punishment with a GOTO command taking the program back to the beginning with all data previously entered lost. This was lazy programming and (despite the miniscule available RAM) it was a personal fundamental that user data was corrected with minimal effort on the part of the human running the program.

As clerical tasks were “computerised” it was also crucial that the user remained in control. We needed to preserve the knowledge of how things were done – as otherwise the next edge case could become a major problem. Software has a duty to educate as well as undertake the drudgery of so many tasks. Fortunately terminals (and micro-computers) evolved and improved. Every advance was applied to the task of improving the quality of the interaction between user and software.

To cut to the chase, it became second nature for me to ensure that the UI (User Interface) was a critical part of every bit of software. So much so that the tools I write for myself typically have a strong UI even as this adds perceptibly to the development time.

So even if I had to explain to you why (say) I have a utility that takes an SQL table definition and outputs boilerplate class code (in C#, VB.NET or Java at choice) together with support stored procedure definitions (with variants for SQLite if required) you could copy the executable to your machine and just run it. You might not appreciate the “why” but the “how” should be obvious.

So given my fervour for strong user interfaces I have some difficulties with the current Python infrastructure. I have in mind a project that would make very effective use of all that Python list handling goodness. My problem would be in sharing any resulting software with others who might make use of it – particularly if it became a commercial proposition.

For the moment Python has to be just for me and is not for sharing. Probably confined to the Raspberry Pi – actually it will be interesting to try out the Kivy library to interact via a touch screen on that platform. So I am not finished yet that's for sure.