Lightning Talks

There was a neat little talk on the different places python is used at NASA, which is always nice to hear. There's actually quite a few external facing NASA websites that use python.

2 other lightning talks caught my attention:

Guido's Keynote

• python 3.1 will break the rule of still supporting previous major releases (e.g., python 2.4 and 2.5 are still very well supported, with bugfixe releases coming out for them, even though 2.6 went gold). With 3.1, python 3.0 (a major release that breaks backwards compatibility) will stop being supported, the idea roughly being that by the time we hit 3.1, there still won't have been any production implementations with 3.0 (there's no way i would put 3.0 in production, personally; and it'll take a while before you see major building blocks such as django support 2.6 and 3.0).

• he would very much like some project porting efforts to 3.0 happen during this conference (and the sprints).

• Guido is on twitter!

• python is 19 years old! Guido has started a blog a little while ago on the history of python; i've been following it since it started, actually and i highly recommend it: it gives background to major decisions, and insights into how it's implemented

  • after 19 years of this, guido makes the point that though we don't know what VM we'll use - maybe we'll all be on ironpython then (for those keeping track at home, most python happens on cpython atm) -, python will still be here for a long long time - python and python developers are too smart to fail
  • there's people who have been using for 15 years now! (i've been using python for about 10 years), which is quite amazing

• retirement? Guido's getting old! No dates or anything, but he doesn't like to travel that much anymore

• mini PEP review:

  • string formatting changes for python 3.1
  • release packaging is still not a solved issue - may never be

• revision control

  • shouldn't be difficult to switch
  • it's been decided that python development will move away from subversion; the decision is now going to center on mercurial vs bazaar
  • there's some talk in git about having a hg or bzr interface to a git backend data repository, which makes the point even more clearly that you should in the future be able to stick with whatever you want to use as a DVCS and interact with any given project

pycon talk page

The State of Django

Obviously a talk i had to attend!

• Jacob Kaplan-Moss has his consulting firm - support django by hiring him!

• django is 5 years old!

• since last year:

  • queryset refactor branch (QSRF) and newforms-admin (NFA) merged into trunk

  • needed a django meetup: djangocon happened

  • 2 books published!

  • appengine hosts django apps!

  • state-of-the-art last year was 1 year-old 0.96: since then 1.0 came out!

  • new and improved documentation system (sphinx, same as python's documentation system)

    • "if you're writing technical documentation, you need to be using sphinx"

  • django signals refact: faster!

  • QSRF, which allowed the Oracle backend to be merged into django core

  • pluggable file storage allows your app to get and refer to files that are not local

  • "best

  • new sessions backend

  • file uploads refact: now with less FAIL

  • autoescape: this is complicated; they preferred to make smart programmers have to jump through hoops to do the right thing, and protect average programmers out-of-the-box

  • databrowse: that looks really neat - go check it out!

  • geodjango was added, a large codebase, a very cool thing

    • holy f?cking cr@p that seems sweet - i'll definitely need to check that out

  • django runs on jython (a very succesfull GSoC project; lets you easily package a django app into a jar you can just give someone else for running on their enteprise J2EE), PyPy, and IronPython!

• django 1.1 coming (it's in beta now)

  • what's new in 1.1
  • ORM aggregation - that's a very cool feature we've been longing for, and actually had to subclass QuerySet to do in a custom way
  • annotation: also very cool
  • query expressions with F objects
  • tests are a lot faster!
  • unmanaged models, proxy models - also very cool (as i'm writing this list i just can't help myself realizing how cool django is)
  • deferred fields - very useful when pulling certain fields on a lot of rows; atm the ORM will convert them all to objects with all their fields, this lets the ORM know it shouldn't select *
  • very cool new admin features: e.g., bulk edition!

• please help! - go to the sprints (i feel bad i can't :( )

• EuroDjangoCon '09 in Prague in May

• USDjangoCon 09, around september, perhaps in Portland, OR

• Py3k:

  • 1.1 will be the last version to support python 2.3
  • so after 1.1, dropping py2.3 support, they'll start porting to 2.6/3.0
  • DB engines might take longer to support python 3.0

pycon talk page

Pinax: a platform for rapidly developing websites

• "Pinax provides what many sites have in common so you can focus on what makes your site interesting."

• If you start a new site, you can start with django, but even with its contrib applications, you'll still need to gather a bunch of other things that most new sites require, such as

  • user registration
  • tagging
  • openid support
  • invitations
  • messaging between users
  • (writing that list is like writing a list of the boilerplate we've had to do for akoha, and of the things we need to do... obviously some research into pinax might be beneficial here...)

• inspired a little bit by a great blog post on modern web infrastructure, which listed the things a modern web site pretty much requires nowadays, and dividing those into "below the line" features (such as an ORM), and "above the line" (a user registration package, with the forms and email confirmation, etc.). Django addresses the former, while pinax is meant to address the latter, so you don't have to.

• Cloud27 is a small social website that showcases what you can do with pinax.

• pinax 0.5 released:

  • external apps for some functionality

    • they sought apps that do one thing and do it well for this purpose

  • local apps for other features

  • supporting librairies

    • they decided to ship with most required librairies included in the package except PIL
    • can't say i much agree with this; you should at least have 2 packages, one without those libs - don't substitute yourself for existing, better packaging systems

  • 2 example projects!

• lots of sites using pinax already

• planned for 0.7:

  • open micro-blogging

  • page-cms

  • new Account app, letting you turn on/off openid, sign up, ...

  • mucho packaging improvements

    • pinax now at the app directory level in your project, so it shares templates and media with it and it easier to package and update

  • etc.

I was very skeptical about this kitchen sink project going in, but i have to say that it would be useful to a lot of people: it lets you bootstrap a new website that has social / collaboration features very quickly and concentrate on the special aspects. I'd be very worried about how they'll handle pinax upgrades, though: if you use pinax 0.5 now to start your new foo.com site, when 0.7 comes out and you'd like the account management upgrades and the new fangled page-cms, will pinax provide db migration scripts? Is the architecture pluggable enough that you could decide to upgrade pinax, but keep the old account management because you've since customized it? Django is very modular and does allow a lot of that; there's always some pains, but overall you can see that it's part of their concerns. For example, the django comments application changed rather drastically how they store comments between 0.96 and 1.0, but they provided very nice comments upgrade instructions with a migration script.

pycon talk page

Django on Jython

project site

Why?

1. For people stuck with having to deploy to a J2EE infrastructure, but wanting to use django and python.

2. But also for another reason: deploying a django application takes many steps, but deploying a J2EE app is supposedly simpler: upload war and restart (i agree that django on cpython needs deployment tools, which we had / still have to build)

   • J2EE does have many enterprise-class frameworks and features for large
   • deployments, and many very experienced people for managing such installations

3. also, java has tons of potentially very interesting libraries, which by deploying your app to django on jython you get to use

4. finally, jython has some cool features

• Packaging your project: jython manage.py war --include-java-libs=jbdcdriver.jar

• also showed how to develop django apps in Eclipse with pydev extension

  • wrote an eclipse plugin (but i'm not sure where it is)

• django's page on deploying django on jython

I think this is very cool, personally. I think there may be a good case for wanting to deploy django apps to jython even though you're not actually stuck with java - there's good enough reasons to do this in and of itself as opposed to a cpython deployment. I've dealt with both types of deployment a fair bit, and i have to say that, especially for an enterprise, this is a very good option for web development. And if you're just hacking something away, you can simply write your django app on cpython like most people do, knowing that django on jython will not be an issue anymore, it'll just be another option.

pycon talk page

Panel: Object Relational Mappers: Philosophies and Design Decisions

This was a panel between different people about ORM's; relatively uneventful, i must say.

pycon talk page

Django BOF

I decided to go to the django Birds of a Feather session, thinking there would be some interesting discussions. After sitting down by Leah Culver (and trying to make conversation but being summarily dismissed) and buying a django shirt (profiting the Django Software Foundation), the room was completely packed, hot and humid as hell, and i started getting a migraine, so i left and went to chat with some friends.

Concurrency and Distributed Computing with Python Today

This was a talk about... well distributed processing! The speaker was very good and entertaining, i enjoyed the presentation. Quite a lot of content - i was taking notes but realized i was typing half of what was on each slide; i recommend watching the video if you're into that sort of stuff, and hopefully the actual slides will go on the talk page as well.

It's mostly an overview of what exists, the gotchas (with threads and the GIL, for example). But with a wealth of references to all the relevant projects out there that should interest you if you're into this subject. The one project i do want to look up after this talk is Kamaelia, a project from BBC Research.

pycon talk page

Abstraction as Leverage

Alex Martelli wins the prizes for coolest voice and coolest accent. I'd expect to hear him on an NPR program (i ? NPR).

This talk was about abstraction in programming, and the fact that all abstractions leak: you can't make an abstraction layer in your architecure that is perfectly abstracted - where a layer above will never ever need to be aware of a layer below. To build such an abstraction would require you to have complete knowledge of everything underneath, which is never going to happen.

It was certainly interesting and full of little tidbits and quotes from all sorts of people. If you do subscribe to this leaky abstractions view, and you're a python programmer, i'd add that you have a winning combination. Python doesn't strictly enforce things like private class members: you can always get through a layer of abstraction somehow. You can drop hints, when you write a certain class, that this variable should be considered private and generally not be tampered with. But users of your class can still get to it if they want - they just shouldn't come crying if their code later breaks. This is part of python's philosophy, and the extreme introspection that python allows is definitely one of its incredible strengths.

pycon talk page