Archive for the ‘Grok’ Category

I little suspected the great chasm that lies between the simple act of agreeing to review a book, and the actual exercise of sitting down later to write the review. It feels quite pleasant, really, to jot off a positive reply to the publisher's polite question. One feels magnanimous for agreeing to help advance our civilization by reviewing a book about Python, and for helping out the publisher in what, after all, are such hard economic times. It is fun when the free copy arrives, crisp and smartly bound.

But then, eventually, one has to write the actual review.

And so, a full four months after that friendly email from Packt Publishing, it is time that I sit down and put together some thoughts about Carlos de la Guardia's first book, Grok 1.0 Web Development. Carlos is a long-time veteran of the Zope and Plone communities, and Grok, of course, is the web framework that places a simple and agile convention-driven engine atop the otherwise notoriously XML-ridden Zope application framework. Grok is an important project, because it packages the technology of Python's oldest and most experienced community of web developers in a way that makes it easy to extend and use.

(more...)

I am home from a relaxing vacation to the Midwest, and while I was gone last week my excellent publishing team released the July issue Python Magazine to the world. I am particularly pleased that two of the feature articles in this issue come from important segments of the Python world that we have not heard much from in previous issues.

First, IronPython, the .NET version of Python for Windows, is the topic of Jonathan Hartley's article about acceptance testing. He illustrates that, regardless of the language in which you write your .NET application, you can deploy simple strategies to make your application testable through a Python test harness, and thereby bring Python's strong flexibility as a testing language to bear on a product that you might be writing in another .NET language.

Second, Malthe Borch, a veteran of the Zope community, shares how he has written Chameleon, one of the fastest template language implementations available for Python. By processing each template and turning it into Python bytecode before it is ever used to render a single page, Malthe eliminates a huge amount of redundant processing as that same code is used over and over again. His library is a key ingredient in the new high-efficiency web frameworks appearing in the Zope world. His work might even (fingers crossed) become one of the components that the Plone community uses as they streamline their framework and move towards a lighter and more agile “Plone 4”.

Other technical topics covered are: the Hadoop map-reduce framework; the concept of hash functions, and how they apply to Python; and the new string formatting operator which Guido hopes will replace all of the percent-signs that currently litter our code. Wrap it all up with an editorial by Steve Holden about EuroPython 2009 and an editorial by me, and you have a complete issue! If you do not find Python Magazine sitting on your local newsstand, then I hope you will avail yourself of a subscription and, as always, let me know what topics you would like to see covered in future issues. Enjoy!

With several packages already advertising Python 3.0 compatibility, it seemed high time to look into releasing my PyEphem astronomy package in an edition compatible with the new language. But I hesitated: how difficult is it really, and how many hours of work will it consume, to port a C-language extension module to Python 3.0?

The answer is that, while the necessary changes were surprisingly easy, they took lots of time to figure out because I did not find them documented in any one place. I offer the following notes to assist any other adventurers who want to experiment with porting their extension modules to 3.0. These notes might also suggest useful additions to the official documentation.

But, first, I need to issue three cautions. To develop under 3.0, you may have to forego several Python tools that you probably thought you could no longer do without. The world of 3.0 is a windswept and icy landscape from which the glaciers have just receded, and you will find the stone tools rather primitive when compared to the comforts of civilization that you enjoy under Python 2. To wit:

• I cannot find virtualenv for 3.0, which is a disaster. This means that you have to create a separate Python 3.0 install, built with a different --prefix option to ./configure, for each development environment you want to create on your box.
• I cannot find a version of the setuptools available for 3.0. This means limiting your setup.py instructions to the primitive vocabulary of the distutils package. For example, I find myself unable to run the PyEphem test suite at this late hour because I have been running it for so long with:

  $ python setup.py test

  that I am not sure how to get it running otherwise.
• Should you succeed in porting your extension module, it is not at all clear how to distribute it. I had expected either a new PyPI to spring into being — since every package will need an entirely different version under 3.0 — or for a sophisticated scheme to appear for registering one pyephem.tar.gz as the Python 2 version and another pyephem.tar.gz for 3.0. But while the most recent version of your package can mark itself as 2-compatible or 3-compatible (or both) using classifiers, there is no way to have two “most recent” versions of a package. Are we supposed to start distributing a single tar.gz that includes the source code for both Python series, and that selects the right code by detecting the interpreter version at the top of the setup.py file?

So if you make the effort to port your code right now, you might find that the shiny new version of your module is all dressed up, but has no place to go. If you experiment with the following steps, though, you will at least be ready when an official distribution channel does appear for releasing your package into the wilds of 3.0.

(more...)

I have delivered my “Zope 3 Component Architecture” talk to the 2008 North American Plone Symposium meeting here in New Orleans. I want to thank the folks at Enfold Systems both for hosting the Symposium, inviting me to speak, and for generously making it possible for me to attend! Here are my slides:

They had asked me to attend so that I could present the Using Grok to Walk Like a Duck talk that I gave at PyCon 2008 back in March. They changed the title, I suppose, to better highlight why it would be of interest to the Plone community; but the change actually helped me to rethink the presentation. I wound up using only the first half of my PyCon slides. For the second half of the talk, which at PyCon had consisted of a crazy sequence of hints and tips about using adapters in your own applications, I instead did a much more successful series of slides about how adapters are actually used in Zope 3 to suit up objects for presentation on the web. I think this made the idea more concrete, and thus much easier to understand for people seeing adapters for the first time.

The talk was well enough received that I should perhaps think seriously about finding further opportunities to share Zope 3 technologies with the Plone community.

After several frustrating weeks learning how to create, edit, and publish a screencast under Linux (about which I will write a separate post), I have now published screencasts of both presentations that I gave at the PyAtl meetup in January. I opened with a talk about the import statement, and where Python packages lived before egg files were invented: The audience seemed most interested in the last section of the talk, where I discuss three techiques for debugging problems with Python's import statement; fast-forward to around 3:00 if you want to catch that part by itself. Next, Jeremy Jones spoke about eggs, Noah Gift introduced virtualenv, and, finally, I got back up to talk about buildout. This was probably my own favorite among the recent presentations I have given, and it's the one I've worked hardest to adapt to a competent screencast: I have prepared a supplement to the above screencast that gives additional hints and tips about using buildout, as well as a link to the source code of the module that I use as my example. Finally, if you're ready to see something a little less polished — something that instead of being a screencast is actually a film of me talking in front of a live audience, and gesturing and jumping around — I filled a vacant lightning-talk slot at our February PyAtl meeting with an impromptu introduction to Kinetic Style Sheets (KSS), using an example application that was still sitting on my laptop after at a Georgia Tech developer's luncheon earlier that week: Now I can finally turn my attention to preparing for my upcoming talk at PyCon 2008 in Chicago! I will be talking about the basic “adapter” design pattern, and how a framework like Zope 3 can facilitate its use. Stay tuned for more information!

In this post, I provide the slides and examples from a recent talk that I gave to some fellow software developers at Georgia Tech. Many of them were not familiar with web frameworks, and I wanted to introduce them to two common concepts: the idea of “convention over configuration,” and the practice of passing inert data structures to a page template rather than letting it access live objects directly. But because I am also really enjoying my work with the new Python web framework Grok, I decided to make it the centerpiece of my presentation (more...)