This email is inspired by a YouTube video of a talk that Jessica McKellar recently gave. I was struck by her analysis that it is hard to remain a popular language (as Python currently is) and her call to action to address friction points that make it hard for a non-Python audience to use Python and applications developed in Python.
Well, here is one. All of the early books one reads on Python compare it to Java or similar languages. Write code once, is the promise, and as long as your target computer has a Python interpreter, your code will run. For Java, I have to say! this really does seem true. Once I have a Java environment installed, Java applications work seamlessly. I download them, execute them, and, unless they are very old and give themselves away by using a non-native set of GUI widgets, I probably forget that I am running Java at all. But as we all know, Python isn't that simple. I'm not talking about the problems of cross-platform GUIs or other such things. I'm taking about the problem of distributing anything more complicated than a single-file program to end users. I realise that I'm not really, either, taking about the much written about Python packaging problem. I was going to berate the packaging documentation for not really helping with the problem I have in mind, but I realised that actually the kinds of packages that the Packaging Guide is taking about are the kinds of things that developers and python-proficient system administrators will be installing. But what about the end-user? The end-user who just wants a blob (he doesn't care about what language it is in - he just wants to solve the problem at hand with your shiny, cool, problem-solving application). He is hopefully using a system on which Python comes as default. At most one might get him to install a new Python interpreter and standard library, but asking him to do more than that is simply asking more than he will do. Will your code run or not? (i.e. without him having to learn what pip is!) There are tools that will package up binaries of python and create something that will even run without an interpreter installed on the target system. If only they were better documented, less fragile and worked consistently with Python 3! Even then, I'm not sure this is the answer - anything like that is bound to be a bit fragile and break one of the attractive features of Python - that all things being equal, I don't need to maintain development environments for every possible target platform to get code to run. What would be nice is something much less complicated. Something , for example, that just takes everything except the python interpreter from a virtual environment, packs it up and turns it into a zip archive that really will run on a user's python installation without any additional steps. There are a couple of tools to do something close to this, but they are hardly well signposted in the python documentation (in fact I only found them with the help of this list), and even these tools need more than a little experimentation to get right. No doubt even here some extra glue or magic would be useful - what is the right thing to do when C modules are needed? But at any rate, I think that some more thought in this area would be very useful. And what about WSGI apps? I regard WSGI as one of the great features of modern Python. But again, end users don't really want to have to learn all about python and proxy servers running in front of special WSGI servers. Most are not going to serve hundreds of thousands of users, but probably do need a little more than one connection at a time. Even if the right solution is to create these complicated setups, I defy anyone to find me a page I could point a competent system administrator (but non-Python developer) at and say, "here is my code, install it in this directory and set up a webserver according to the instructions on this single web page and everything will just work." We are even further away from saying, "Here is a special zip file. Make sure you have a Python 3 interpreter ready and then just treat this file as you would any other service on your system. Have it started by whatever daemon manages services on your server, and it will all just work and be able to handle a reasonable number of users with a reasonable level of security and reliability. Of course, if you end up with more than a few hundred users, you will need something more specialised." Python *packaging* looks as if it is getting sorted out. Pip is going to be part of Python 3.4 and PyPI works very well. The instructions on the net for packaging things for a Python audience are extremely good. Sending python code to other python developers is extremely easy. But it is not easy to send code to non-python developers. The promise that you can just get your users to install a Python interpreter and then give them code to run on it is a worthy dream. Perhaps all the pieces to do this all seamlessly exist already, but if so they need much better documentation, somewhere that it is really easy to find it. IMHO, anyway. Nicholas
-- https://mail.python.org/mailman/listinfo/python-list
