EuroPython Day 1
| Posted: | 2007-07-16 11:34 |
|---|---|
| Tags: | OpenID, Pylons, Python, Talks and Conferences |
Well, here I am in Vilnius in Lithuania at EuroPython 2007. I've already bumped into a load of people I already know and have been pleased to see Pylons used in three of the talks already!
Here are some notes on the talks I've been to:
Extending Python with EasyExtend
I was actually planning on going to Object databases for Python but I ended up in the wrong room but was pleased I did. EasyExtend is a Python package which allows you to create new language syntax. This can be used to implement Python 2.5 language features in Python 2.4 or create a new programming language completely. I'm particularly interested in it because it could be used to restrict access to certain Python features so could potentially be used to provide scripting for users using a cut-down and safe version of Python. This might be handy in say a web-based spreadsheet application where a custom language could be implemented for the formulae.
Seamless object persistence with ZODB
I hear a lot about ZODB because Zope is used extensively on other projects at the Institute of Child Health where I work but I've never actually used it myself. This talk was a good introduction. Basically you have to ensure you use special persistent classes for lists and the like in order for ZODB to keep track of changes you make to them. As long as all your objects are derived from the special persistent classes all works well. One interesting method you can use on transactions is doomed() which will prevent any further commits but will still allow you to access all the data as it currently stands for use in debugging code.
The Storm Object-Relational Mapper
This talk outlined Storm, a new object relational mapper created by Canonical which hadn't been widely announced to the community before. Key features are that it works with normal Python classes, is very simple and has more lines of unit tests than it does actual code so is likely to be very stable. It has also been used in production by Canonical for over a year I think this would be my object relational mapper of choice if I were to use an ORM. It has similar functionality to SQLObject or Elixir, is much simpler and more stable than SQLAlchemy and is well supported by Canonical. The speaker also claimed it was very very simple to implement new drivers and had a very nice SQL query layer. Definitely worth a look if you are interested in ORMs.
Case study of a Pylons project
In this session Max Ischenko discussed his experiences of converting a Ukrainian developer's site written in PHP to use Pylons. Overall Max seemed very pleased with the how Pylons performed although he found he had to do quite a lot of the groundwork himself. View the slides if you are interested in his thoughts.
KSS, Ajax development with style
KSS effectively lets designers and HTML writers handle JavaScript functionality in the same way they would use CSS and provides a clean interface to allow developers to provide the functionality those designers can use. This was one of the most interesting projects I saw at EuroPython and I spent a couple of hours discussing it afterwards with Jeroen Vloothius, a Plone developer who works at Pareto.
KSS lets you apply JavaScript to elements via CSS-style stylesheets called KSS files. This means you abstract away all the JavaScript used by your appliaction into simple rules that even a non-technical user can apply to their HTML in the same way they would apply CSS. It also means that you can use any JavaScript library you like to implement the KSS which means if you swap JavaScript libraries later you have a clean interface to implement.
The second important feature if that KSS lets you determine the actions to perform after an AJAX request on the server side via an HTML document returned to the browser rather than needing to do it client side. This is tremendously useful because after all it is the developers who need control over what happens after an AJAX request, not the designers. If you've ever come across a problem where someone has used some nice bit of JavaScript to update a status but failed to notice that the status is also displayed on other parts of the page which need updating too then you'll understand why this is useful.
KSS is already used in Plone and Jeroen applied it to the Pylons QuickWiki tutorial code to demonstrate that it was cross-framework too. While demoing it one of the Python developers in the audience asked how he managed to get it running so fast (it was just running the standard Pylons server though) so it just goes to show that if you can use AJAX effectively it can really impress people and KSS represents a great tool for effective AJAX use.
One feature which would be nice are the ability to update the URL on each click (a la Dojo) to provide an AJAX history in such a way that all the links can use an AJAX replace but that if the user ever hit refresh on the current URL they would see exactly the same page. I'm having a think about how this paradigm could be implemented in Pylons.
Using FormEncode for web data validation
This talk was given by a friend of mine, Graham Stratton and gave a good insight into how to use FormEncode. The key points were that FormEncode itself, despite its name, is simply a tool for converting data from a particular format to Python and back again. In the context of web forms, FormEncode converts form data to Python objects and can then covert Python objects back from Python to web form values again. How the form data is then displayed is up to the developer but FormEncode also comes with a tool called htmlfill which can parse an HTML fragment, extract field names and generate a new HTML fragment with all the values and errors set, ready to redisplay. There is no requirement to use htmlfill, but it is a useful approach for populating fields in a very generic way.
This talk by Philipp von Weitershausen really interested me. What he has been trying to do is take Zope 3's WSGI support and see how far he can integrate Zope 3 with Paste in an effort to end reliance on Zope 3 instances and instead encourage developers to use Zope 3 more like a library where they import, setup and use only those bits they need. Philipp produced some paster create templates to create a sample project which can then be served by paster serve. This also meant that he could add all the Pylons middleware to Zope 3 and at one point he demonstrated a TurboGears app and a Zope app mounted using Paste to a WSGI app and then served together on the same server. I hadn't realised just how far Zope had come in terms of its refactoring and as a result much of Zope 3 may very well become accessible to projects such as Pylons in the very near future, particularly with this sort of work going on. If any members of the Zope community want WSGI, Paste or Pylons advice related to this sort of opening up, please get in touch, I'm keen to help.
Other Talks
In the afternoon I saw py.test: towards interactive, distributed and rapid testing and unittest is Broken. There seem to be lots of testing tools available at the moment and nosetest and py.test in particular seem very similar. My instinct is to wait a bit longer to see how the various alternatives settle down.
Keynote
After the talks Simon Willison delivered his keynote on OpenID and as well as pointing out my AuthKit package as a Python OpenID implementation he announced that he would be working with the Pylons community to help unify the Django request and response with the Pylons one. If things go well we might have a chance to sprint on this on Wednesday or Thursday. I've heard Simon speak about OpenID quite a few times now but every time his arguments get more refined and his vision for decentralised social networks based on OpenID and web services becomes more focussed. Simon encouraged developers to work towards an open alternative to the Facebook platform. As always, I agree with virtually everything he said.
After the keynote and a quick chat to Nat and Simon I headed out into Vilnius with Graham to explore the city based on some of Natalie's recommendations and Graham and I eventually ended up in the traditional-style bar/restaurant which Guido had chosen for the evening. It was made mainly of wood and had a tree growing inside. Beer was on Google and we met two developers who had travelled all the way from South Africa.