Relearning python, day 4: The ecosystem
First, sorry about not blogging- all of the last 3.5 days were spent working on my wedding invitations, and making 100 jars of peach jam. I’ve just gotten home and am very thankful to have inlaws-to-be with a very large kitchen that I was able to use to make so much goddamn jam, and I don’t want to look at a peach for a few days.
I’m mostly finished my service architecture and have moved onto developing the client and UI. As this has moved from the realm of ‘normal’ programming to more ‘framework driven’ programming, it has exposed me to a completely new part of python and one I wasn’t too familiar with- and one I certainly didn’t fully understand the repercussions of- the python/open source ecosystem.
I’ve worked in two other ecosystems- the 3ds Max/Autodesk system, which is to say it is all build-it-yourself because the quality of ‘modules’ you find in the wild blow really hard. And the Microsoft/.NET ecosystem, in which most things are provided by MSFT, with a spattering of open-source projects (NLog, NUnit, NHibernate, I think that’s all I’ve really used other than codeproject code we ‘adopted’). There just weren’t many options available on what you used for X- you used what Microsoft provided, augmenting it if needed.
Python is not at all like that. I need to turn my service project into an actual service that can be accessed by a client. If this were .NET, I’d use (and have used) WCF. For an internal application (no outside compatibility issues), there’s no decision chart- just use WCF with configurations optimized for .NET. With python, I have a dozen modules to choose from- a full framework like Twisted, simpler systems like CherryPy, xmlrpc servers, jsonrpc servers, etc., and each one is a package with unique considerations. I need to also build a UI. If this were .NET, I’d choose either WPF for a desktop app or ASP.NET MVC for an internet app. With python, I have to choose from Tk, Wx, Qt, and more. I don’t even know what to do for web UIs. I eventually decided on pyjamas, a framework that compiles your python into javascript/html.
I still haven’t gotten everything working. Which is not surprising, because of two unfamiliar attributes of the python/OSS community- 1) They are *unix based. I have never used a Unix system, and have no desire to yet. So things like pyjamas, which is still alpha/beta and developed on Linux, has some hiccups getting set up on a Windows machine. It also means lots of the documentation on modules reads as a somewhat foreign language, though I’m sure I’ll learn how to translate Linux->Windows more and more (I figured out I couldn’t install pyjamas to a path with a space in it!).
And 2) the projects are run by developers. So what I find is incredibly innovative and generally well written software with little external documentation, and more commonly, documentation written for people just like them. That is to say, much more familiarity with python, Linux, and dependent/related frameworks and systems. So there is a lot of trial and error and head banging trying to get things working, often. Compare this to Microsoft, where any released feature is fully documented including a full battery of tutorials and supporting information written, usually, in the simplest terms possible.
For example, when I wrote my first WCF project, it took maybe 25 minutes to get a server/client running. It took several more days to figure out the configuration issues and server/client issues like how things are sent over the pipe, but it was all in all pretty simple. Doing the same in python, it took me several hours just to decide what framework to use! And because of the relatively less, and more foreign, documentation and examples, evaluating them was more difficult. I will probably pick a jsonrpc system for easy use with pyjamas.
Which all seems to gel pretty well with my python hypothesis so far about the actually steep ramp-up and advanced-level requirement to use it effectively.
Next time, I’ll go over my UI frustrations, and why I chose pyjamas.
[…] UI portions of my data aggregation service. I spoke about client/service protocol frustrations in my last post, but the most frustrating part so far has been figuring out the UI. There are three parts of […]
The python web application framework web2py has a nice jsonrpc interface to pyjamas builtin. web2py is well documented in both an online book and a pydoc api description.
If my current implementation proves too difficult to deploy (especially on TAO’s linux server), I’ll take a look at that fore sure. Thanks!