Matt Croydon::Postneo

Category: Python

  • WSDL for Series 80

    I just saw the the Nokia WSDL-to-C++ Wizard fly by my aggregator:

    The Nokia WSDL-to-C++ Wizard is a Microsoft Visual Studio 2003 .NET add-in that creates Symbian C++ code for accessing a web service described by a WSDL file. The code generated by the wizard uses the Service Development API of the Nokia Series 80 Second Edition developer platform and the generated code can therefore only be used on S80 2nd edition compatible phones. The preferred way to use the wizard is together with the Nokia Developer’s Suite for Symbian OS 1.1.

    This should broaden the horizons for C++ app devs targeting Series 80 2nd edition. I’m a big fan of RESTian web services, especially on a mobile device. I wonder how much work it would take to get one of these SOAP toolkits running on Python for Series 60.

  • The Django Shuffle

    Lots of changes are happening in the newly formed Django world these days. Tons of bugfixes and feature additions have been streaming in to the subversion repository. One of my recent favorites is Changeset 384 which adds a django-admin.py inspectdb command. It’s not perfect yet but it should help out people trying to integrate existing databases with Django. The new command will do its darndest to output a Django model given a particular database name.

    In other news, congrats to Eric (slashzero) on the new gig in Naples and to Adrian (adrian_h) on his new gig at The Washington Post.

    Update: Hugo’s at it again and has notes on using Django with Apache and mod_fcgi which build on his experience with Django, lighthttpd and FastCGI.

  • The Revolution Will Be Geotagged

    Over the weekend I’ve been working on a Python for Series 60 project that I thought up a few days ago while exchanging information with Gustaf between Google Earth instances. It really should have hit me when Google Sightseeing packed its sights in to a KML file, but what can I say, I’m a little slow.

    After sending a .kml file via email to Gustaf, I decided to take a look at what exactly made up a .kml file. I started to drool a little bit when I read the KML documentation. The first example is extremely simple yet there’s a lot of power behind it. A few lines of XML can tell Google Earth exactly where to look and what to look at.

    Proof of Concept

    With this simple example in mind, I started to prototype out a proof of concept style Python app for my phone. Right now everything is handled in a popup dialog, and for the time being I’m just going to save a .kml file and let you do with it as you please, but over the next few days I plan to re-implement the app with an appuifw.Form, get latitude and longitude information from Bluetooth GPS (if you’re so lucky), and work on smtplib integration so that the app can go from location -> write KML -> send via smtplib.

    Rapid Mobile Development

    When I say that I’ve been working on this app over the weekend, that’s not strictly accurate. I prototyped the proof of concept over about 20-30 minutes on Friday night using the Python for Series 60 compatability library from the wonderful folks at PDIS. I then spent the rest of some free time over the weekend abstracting out the KML bits and reverting my lofty smtplib goals to saving to a local file on the phone. I’m not sure if the problem is due to my limited T-Mobile access or if I need to patch smtplib in order to use it on my phone.

    There’s also one big downside to trying to use smtplib on the phone, and that’s the fact that smtplib (and gobs of dependent modules) aren’t distributed with the official Nokia PyS60 distribution, so if I’m going to distribute this app with smtplib functionality, I’ll have to package up a dozen or two library modules to go with it. I’m going to mull it over for a few days and see if I can get past my smtplib bug or investigate alternatives.

    from kml import Placemark

    I’ve started a rudimentary Python kml library designed with the Series 60 target in mind. It’s rather simplistic, and so far I’ve only implemented the simplest of Placemarks, but I plan to add to it as the need arises. It should be quite usable to generate your own KML Placemark. Here’s a quick usage example:

    >>> from kml import Placemark
>>> p=Placemark(39.28419, -76.62169, \
"The O's Play Here!", "Oriole Park at Camden Yards")
>>> print p.to_string()
<kml xmlns="http://earth.google.com/kml/2.0">
<Placemark>
  <description>The O's Play Here!</description>
  <LookAt>
    <longitude>-76.62169</longitude>
    <latitude>39.28419</latitude>
    <range>600</range>
    <tilt>0</tilt>
    <heading>0</heading>
  </LookAt>
  <Point>
    <coordinates>-76.62169,39.28419</coordinates>
  </Point>
</Placemark>
</kml>

    Once I have my Placemark object, saving to disk is cake:

    >>> f=open("camdenyards.kml", "w")
>>> f.write(p.to_string())
>>> f.close()

    If you have Google Earth installed, a simple double click should bring you to Camden Yards in Baltimore. The simplicity of it and the “just works” factor intrigue me, not the fact that this can be accomplished in a few dozen lines of python but the fact that KML seems so well suited for geographic data interchange.

    Camden Yards in Google Earth

    It’s About Interchange

    If you are really in to geographic data, and I mean so at an academic or scientific level, KML probably isn’t the format for you. You might be more interested in the Open Geospatial Consortium’s GML (Geography Markup Language). It looks like it does a great job at what it does, but I’m thinking that the killer format is aimed more at the casual user. KML is just that. From a simple Placemark describing a dot on a map to complicated imagery overlays, KML has your back covered. I find the documentation satisfying and straighforward, though I’m no expert on standards.

    In the very near future conveying where you are or what you are talking about in a standard way is going to be extremely important. Right now there’s only one major consumer of .kml files and that’s Google Earth. Expect that to change rapidly as people realize how easy it is to produce and consume geodata using KML and .kmz files (which are compressed .kml files that may also include custom imagery).

    I would love to see “proper” KML generators and consumers, written with XML toolkits instead of throwing numbers and strings around in Python. I would love to have a GPS-enabled phone spitting out KML using JSR-179, the Location API for J2ME. I hope to use Python for Series 60 to further prototype an application that uses a Bluetooth GPS receiver for location information and allow easy sharing of geodata using KML.

    The Code

    If you’d like, take a look at the current state my kml Python library, which is extremely simple and naive, but it allows me to generate markup on either my laptop or N-Gage that Google Earth is happy to properly parse. A proof of concept wrapper around this library can be found here. I hope to expand both in the coming days, and I hope to soon have the smtplib-based code working properly on my phone with my carrier.

    Update: Oops, forgot to add the <name/> tag. Fixed. The name should now replace the (ugly) filename for your Placemark.

  • Pythonic Wensleydale?

    I’m guessing that the PyPI folks got tired of pronounciation issues and being confused with PyPy. And so cheeseshop.python.org was born, or at least I’m assuming that’s how it came about.

    I wonder if they’ve got my Wensleydale in yet.

    Update: Looks like it’s just a hostname switch according to AMK.

  • Django on Dreamhost via FastCGI

    Thanks to the hard work by Hugo and an excellent efford by skabber and jdanks, there are now instructions for installing Django on Dreamhost using FastCGI on the Dreamhost Wiki.

    I’m still amazed at how quickly Django development is happening and how quickly a community is being built out around it. Keep an eye on the Django Trac timeline for a glimpse at the latest and greatest.

    Update: Sorry about the mislink, Jay.

  • Django + lighttpd + FastCGI

    Hugo has taken the plunge and provides installation instructions for Django + lighttpd + FastCGI. Thanks, Hugo!

  • Django: Trivial Patch

    Last night I ran across a deprecation warning when running django-admin.py startproject <projectname>, so I went to file a ticket but found that someone else had experienced the same problem. I looked at the solution, and on the surface it looked like the fix involved replacing from whrandom import choice to from random import choice. Indeed that was all it took, so I submitted a (trivial) patch and continued to bang on Django a bit more.

    That trivial patch made me really wish that there were unit tests for Django. I would have felt a lot better knowing that after applying my patch n tests still passed with flying colors. Without a test framework in place, I really had no idea if my trivial search and replace broke something. It’s possible that somewhere in the code was really expecting some behavior specific to whrandom that was just slightly different than the behavior of random.

    I’m going to hunt around for other little trivial fixes that don’t require carnal knowledge of the codebase and submit patches if I can come up with a fix. At the same time I hope that Nelson’s test suite ticket gets noticed. I wouldn’t mind doing some of the dirty work once a framework is in place, but as always I defer to Adrian and the core Django team when it comes to policy and implementation.

  • Keeping Up With Django

    It’s been quite amazing watching this framework called Django, pulled from a production environment, evolve in realtime right before my eyes. Adrian has been committing changes left and right, fixing bugs, adding features, and most importantly lowering the barrier for new users. Docs and tutorials are being clarified, things made simpler, and a few of those nagging problems are dissapearing in front of my eyes.

    Yesterday Adrian modified the cookie system so that we didn’t have to add a custom setting in order to make it work. He’s also moved DJANGO_SETTINGS_MODULE to a Python variable so you should no longer have to set an environment variable in order to tel the system which module you want to run. Strike that, you still need the environment variable, the name is just user configurable. (Thanks Stefano!) And of course the addition of django-admin.py runserver lets you bypass mod_python or another WSGI-compliant server while you are just checking out the framework or during initial development.

    jango team and everyone in the quickly expanding community. If you’re having trouble with something, hop on #django at Freenode, there’s probably someone else in there who has experienced the exact same thing. And don’t forget to svn up often!

    Now that I’ve gone through the tutorials and have reasonably wrapped my head around the framework I plan to work on a small project to flex my newly found Django muscles.

    Update:

    As always, Adrian has made our lives simpler, this time with Changeset 247:

    Added ‘–settings’ option to django-admin. This specifies which settings module to use, if you don’t want to deal with setting the DJANGO_SETTINGS_MODULE environment variable. Refactored django-admin to use optparse. Updated the tutorials to use ‘–settings’ instead of environment variables, which can be confusing.

  • Pimp My Django

    Pimp My Django

    Yeah, baby! Thanks to tons of SVN updates, I’ve managed to plow through the second Django tutorial unscathed. I’m really impressed with the admin interface and how a dab of Python can do stuff like create a sidebar or create a rocking search interface.

    Huzzah!

  • Django: Making it Easier

    Yes! Adrian has just commited a patch that bypasses mod_python completely!

    mcroydon@mobilematt:~/django/proj$ django-admin.py runserver
    Starting server on port 8000. Go to http://127.0.0.1:8000/ for Django.

    svn up in your django_src dir and enjoy.

  • Django Gotchas

    I know that a lot of these things will get ironed out or explained more clearly once the platform matures and more people start using it, but here are some tips for early Django adopters trying to get through the tutorials:

    1. Don’t name your project test. I know it sounds like a good idea now. I did the same. Trust me though, at the beginning of Tutorial 2 you’ll start kicking yourself when you run in to namespace collisions with the test module. In order to make this warning a bit more abstract, you’re best off not naming your project anything that is a Python module in the Python Standard Library
    2. Your project directory should be somewhere in your Python Path. Under Linux your best bet is to set the PYTHONPATH environment variable. Here’s the gotcha, if your project is in /path/to/project, you actually want to set your PYTHONPATH variable to /path/to. On a per-session basis you can do this by doing something like export PYTHONPATH=/path/to
    3. In order to really use django-admin.py as often as you’re going to, you really want to symlink it to /bin or /usr/bin. For me (again, under Ubuntu having checked out Django via Subversion), ln -s /usr/lib/python2.4/site-packages/django/bin/django-admin.py /usr/bin/django-admin.py did the trick.
    4. Really pay attention to the install instructions and make sure you symlink your django install to /usr/lib/python/site-packages correctly.
    5. I’m still dealing with the newbie cookie authentication bug that tends to creep up partway through the second tutorial, but I was able to get the admin login to pop up by using the following settings for Apache2 and mod_python (with special thanks to #django and the Django on OSX installation guide): 
      <location /admin/>
        SetHandler mod_python
        PythonHandler django.core.handler
        PythonPath sys.path+['/home/mcroydon/django']
        SetEnv DJANGO_SETTINGS_MODULE proj.settings.admin
        PythonDebug On
</location>

      The PythonPath to the directory containing your project is again quite critical. This is where the test collision will show up if you’ve been foolish enough to name your project test. Make sure that DJANGO_SETTINGS_MODULE points to your project. This worked perfectly for me under Ubuntu Hoary, but YMMV. PythonDebug On is your friend here and turns a plain jane 500 error into a traceback.

    Gotchas like these are going to have to be minimized in order to not scare away newbies and also enable that “running start” feeling that you get with Rails. I’m sure that a few of these are mitigated by setup.py in the tarball and the rest should be made a lot easier once WSGI support is added (and I’m glad to hear that adding a built-in server is on the list somewhere) should take care of the rest.

    I do have to say that so far (gotchas aside) I’m really impressed with the platform. It’s great to be able to work with the Python interpreter to flush out some test data (you can do similar things with the Ruby interpreter with Rails, but Python is my native language). I also got warm fuzzies when someone asked if there was a mail module for Django. Heck, Python has an awesome standard library, why not use it?

    Thanks again to everyone in #django on Freenode for all the help and guidance. Now it’s time to get back to that login gotcha.

    Note: Django is a moving target right now. Since I wrote this early this morning, support for a standalone server has been added (just after WSGI support was added) and lots of little bugs and niggles are being taken care of as I type.

  • Django: Python on Rails?

    Let the buzz over Django begin. I first saw it fly by very early this morning as Clint Ecker pointed to some documentation. Simon Willison has given it a proper introduction this morning.

    I definitely need to take a close look at Django if it can approach the productivity of Rails while speaking my native Python. I could be missing something, but I think one very important thing that Django needs in order to have that running start in development productivity is to ship with a small HTTP server available by default. Rails uses WEBrick for this and allows development without the need to mess with Apache or lighttpd in order to start coding. It should be trivial to add similar functionality to Django (with CGIHTTPServer and all).

    I don’t mean to rag on the new framework on the block. I think Django has a ton of potential. It’s off to the right start, having been extracted from a working environment being worked on by some really smart people.

    We’ll see how this turns out, but I’m extremely excited.

  • Killer Mobile Interfaces with Python and Maemo?

    Thanks to INdT‘s hard work, Python as well as PyGame are available for Maemo and the 770. This got me thinking about how cool it would be to use PyGame on Maemo to develop simple (but really good looking) apps with that “video game menu” feel to it. Killer apps like MythTV Freevo have proven that you can use PyGame to create killer interfaces.

    I’m going to put this somewhere on my long list of things to do in my spare time, but it would rock if someone ran with this. What do you think?

  • Python For Series 60: 1.1.0 Pre-Alpha

    There’s a new version out, 1.1.0 Pre-Alpha. Grab the .SIS installer for first edition devices (3650, N-Gage, etc) or for 2nd edition devices. Don’t forget to pick up the first edition or second edition SDK

    I’ll read over the new API docs tonight and hope to find all kinds of juicy morsels.

    Update: Erik Smartt fills in some details on his weblog. Thanks again to the whole Python for Series 60 team for all the hard work.

  • Python for Series 60 App: QuoteGrab

    Introduction

    I had 15-20 minutes to kill Wednesday night before class, so I wrote the first fully functional version of this little hack/app. It first prompts the user for a stock ticker symbol (like NOK, AAPL, YHOO). For now it expects your stock ticker symbol to be in uppercase. After the input is received, it grabs a .gif image from Yahoo! Finance, then displays the image using appuifw.content_handler. Once you are viewing the image you can zoom in, zoom out, and view the image fullscreen.

    After I got the basic app working, I took a few minutes here and there over the last few days to work in some basic exception handling. I wasn’t able to catch a TypeException error thrown from content_handler, so I have it checking if content was downloaded successfully before launching content_handler.

    Screenshots

    Quotegrab asking for a stock to look up Initial Content_handler view of the downloaded graph Zooming in using the content_handler controls Zoomed all the way in

    The first screenshot is asking for a stock ticker symbol to look up. The second is the initial zoom level when content_handler is called on the downloaded graph. The third screenshot is zoomed in a bit using the content_handler controls. The last screenshot is a fullscreen view of the graph.

    Requirements

    • A Series 60 phone, 3650 or newer (tested on N-Gage and 6630)
    • Python for Series 60
    • GPRS network access (not just WAP access)

    Download

    quotegrab.py

    Installation

    Download quotegrab.py and transfer it to your phone using Bluetooth, IR, email, or other means. When you open in from your inbox, it will prompt you for installation. If you have an MMC card reader or N-Gage, you can place it in /system/apps/python/my on your MMC.

    License

    QuoteGrab is licensed under a BSD-style license.

    TODO

    While a complete running app, this 62 line Python program does one thing, once, and does it pretty well. I would like to widen the scope of this app in the future to allow you to download and view the graph of the stock over 5 days, 3 months, or any other length of time that Yahoo! Finance offers. I would also like to add the ability to download and display basic stock information such as current price, change, and other vital stats. It would also be really awesome to be able to link to Yahoo! mobile for more information.

  • Rapid Python for Series 60 Development

    Right now I’m writing Python for Series 60 apps on my Ubuntu laptop and testing with a Nokia N-Gage (the infamous taco). The taco is an excellent (and inexpensive) development/testing platform for Python for Series 60 because it offers a USB connection that once connected allows you full access to the contents of the MMC. After a few rounds of navigating to the right spot on the MMC and then dragging my .py file using Nautilus, I decided to automate the process a bit. Here’s a little bash script (I call it py2phone) that has made my life quite simple:

    #!/bin/bash
cp $1 /media/usbdisk/system/apps/python/my
sudo umount /dev/sda1

    It copies the first command line argument to the correct spot on the MMC and then handles the umount command so that I can immediately disconnect the USB cable and test on the device. I usually copy to the device after running through it using the PDIS Series 60 compatability library, which helps me find stupid syntax errors before copying to the device. The comatability library sits on top of wxPython and implements most of the basic appuifw functions. I would really like to stub out content_handler to acknowledge the call rather than stacktrace, but other than that the compatability library absolutely rocks for debugging before transfering to the device.

    Here’s my development cycle, which when I’m fixing, tweaking or experimenting, can last all of a few seconds:

    1. Edit file.py file (I’m currently using GEdit for syntax highlighting)
    2. run python file.py at the command line to run through the app on the laptop
    3. ./py2phone file.py
    4. Unhook USB cable, test app on device

    The next step is to automate this process further by extending my little bash to handle the test call, ask if everything went okay, and then conditionally copying the file to the phone and unmounting the device.

  • Useful Python for Series 60 App: Dict2Go

    Over the past few weeks I’ve been on the lookout for pure python modules that run on Python for Series 60. I have managed to make use of a few cryptography modules (including Rijndael, DES, and Blowfish) as well as parse tag soup using BeautifulSoup.

    While I was able to highlight some pure python packages and modules that worked well on Series 60, I really wanted to put together a quick simple app that was actually useful. After searching around for modules and services that would be great to access from a mobile device, I fell in love with John Goerzen’s dictclient.py. The module is a consise and well documented client that speaks the dict protocol.

    Using Goerzen’s module, I have put together a simple GUI using the native widgets provided by appuifw. I was able to knock out the app in a little under an hour or so first by prototyping using the wxPython-based PDIS Series 60 Compatability library on my Linux laptop. From there a few iterations of tweak, test, tweak on my N-Gage (which is great for this type of thing because of the USB cable). Until my GoPhone SIM shows up tomorrow I’m without non-WAP data, so Gustaf was kind enough to test and send me a few stacktraces before I fixed a stupid typo or two in my code.

    Screenshots

    Dict2Go Input Dict2Go Results

    Installation

    To use Dict2Go, you will need Python for Series 60 installed on your phone. If you have a 3650, 3600, N-Gage, or N-Gage QD you will want to snag PythonForSeries60_1stEd_SIS.zip. For newer phones (6600, 6620, 6630, 7610, etc) you are looking for PythonForSeries60_2ndEd_SIS1.0.1.zip. You will also need a way to put the library file dictclient.py in your Python libs directory. Christopher Schmidt sent in a much easier way to install dictclient.py:

    For installing the dictclient.py, you can just send the file to your phone and install it as a Library module using the standard Python installer. There’s no reason to use Fexplorer or an MMC reader for that.

    My way (the Taco way) is still an option, though it’s much harder than it could be. You can copy the files using an MMC card reader (or your N-Gage) or by transfering the file to your phone and using FExplorer. If you have installed Python on your MMC (which you should have), put dictclient.py in E:/System/libs. One the library is in place, you can either place dict2go.py in E:/System/apps/Python/my or just transfer it to your phone and install it from your inbox.

    Download

    Note: this is a quick but functional hack. I think that it’s quite useful in its current form, but I have lots of plans to make it more fault-tolerant and user friendly as well as add more features and functionality. With that out of the way, there are a few ways to download Dict2Go:

    License

    Dict2Go is released under the GPL, version 2 or greater, as is the dictclient.py library that does all of the hard work. A copy of the license can be found in the zip files and tarballs.

    ToDo

    As I’ve said before, this is a quick hack, but I like it. The dict server is currently hardcoded to talk to dict.org, but that can be changed by editing the source if you really want to. Dict2Go also grabs the first definition it finds. I hope to make both of these configurable in the future. I also have lots of plans for UI improvements including a main app loop so that you can look up as many words as you want until you are done. I will do my best to get new stuff out the door as quickly as possible.

  • Minor Python For Series 60 2.0 Update

    Sweet! I just saw the release fly by my aggregator and thought I would let everyone know: There’s a new Python for Series 60 release for 2.0SDK phones available at Forum Nokia. This looks like a small update for newer phones (6600, 7610, 6630). The only change in the release notes that I can see involves invoking an install dialog when downloading python files from the web rather that running them directly.

    While this is a minor update, it’s forward progress. Hopefully the enhancements and extensions that have been demoed will work their way through the release process as quickly as possible.

  • More Python for Series 60 Crypto: Rijndael

    Rijndael on Series 60

    During my search for pure python Nirvana I came across Bram Cohen‘s rijndael.py. It can work with strings of length 16, 24, or 32. Here’s the sample code that ran successfully (albeit slowly) on my Taco:

    # Make sure rijndael.py is in your libs dir
from rijndael import rijndael
# key must be 16, 24, 32 characters long
key = 'sixteencharacter'
r = rijndael(key, 16)
# must encode/decode in the chosen blocksize
print 'Encoding/Decodingnusing Rijndael...'
plaintext = 'themonkeygoeswoo'
ciphertext = r.encrypt(plaintext)
print r.decrypt(ciphertext)

    It took its sweet time to run, but isn’t much more painful than waiting for import urllib, so it’s not the end of the world. It requires copy and string, which I’m not sure are in the Nokia distribution, but it works just fine if you dump the Python 2.2.2 source libraries in to your libs directory.

    Add this one to your mobile cryptography toolbelt.

  • PyCon Day 3: PyBlosxom

    Yes, that’s right. I still have notes from PyCon that need a proper writeup. Ted Leung‘s presentation on PyBlosxom. PyBlosxom is an implementation of Blosxom that is Pythonic while maintaining the original blosxom zen.

    Like any old blosxom variant, you don’t need a database to run PyBlosxom. Posts are stored on the filesystem, and most of the hard work is accomplished by PyBlosxom interacting with the filesystem. You can use whatever editor you feel most comerfortable with to create your posts. A post is stored somewhere in a folder heiarchy that also acts as categorization.

    Most of the base functionality in PyBlosxom is implemented in plugins. There are also a multitude of plugins that can enhance your PyBlosxom weblog, including archives, calendar navigation, xml-rpc interfaces for the Blogger and MetaWeblog API, autopinging, logging, lucene integration, post markup engines, and more.

    Developing PyBlosxom plugins seems to be a breeze too. Plugins are just Python modules that supply callback functions. They’re called by PyBlosxom at specific times, and multiple plugins can be chained together that can be called in alphanumeric or a specific order. Plugins get all of the information they need to work with in dict form. They are given http request information, configuration data, and other data that it may need and need to just manipulate that data to get the job done.

    There are a ton of plugins available already, but Ted would really like to see some more comment plugins, especially with picture challenges and comment moderation.

    Ted’s talk was motivation enough for Erik Smartt (who was sitting next to me in the back of the auditorium leeching power) to switch from his home grown blog software to PyBlosxom. He also converted his wiki markup code in to a PyBlosxom plugin with very little effort. Hopefully he’ll find a solution to multiple categories too.