Planet Python

Last update: November 03, 2009 06:44 PM

November 03, 2009

---

Reinout van Rees

Delft

November 03, 2009 04:18 PM

---

Kenneth Reitz

Cloud Computing: Yin and Yang

Life is good.

Of course, people use this technology for both good and bad. In fact, a few days ago, someone wrote a tutorial for
Cracking PGP with an Amazon EC2 instance & EDPR. Again, life is good.

Remember: if you create an successful open door web service,
all people, good and bad, will come.

November 03, 2009 02:32 PM

---

Alex Gaynor

Introduction to Unladen Swallow

Unless you've been living under a rock for the past year (or have zero interest in either Python or dynamic languages, it which case why are you here?) you've probably heard of Unladen Swallow. Unladen Swallow is a Google funded branch of the CPython interpreter, with a goal of making CPython significantly faster while retaining both API and ABI compatibility. In this post I'm going to try to explain what it is Unladen Swallow is doing to bring a new burst of speed to the Python world.

In terms of virtual machines there are a few levels of complexity, which roughly correspond to their speed. The simplest type of interpreter is an AST evaluator, these are more or less the lowest of the low on the speed totem poll, up until YARV was merged into the main Ruby interpreter, MRI (Matz Ruby Interpreter) was this type of virtual machine. The next level of VM is a bytecode interpreter, this means that the language is compiled to an intermediary format (bytecode) which is then executed. Strictly speaking this is an exceptionally broad category which encompasses most virtual machines today, however for the purposes of this article I'm going to exclude any VMs with a Just-In-Time compiler from this section (more on them later). The current CPython VM is this type of interpreter. The most complex (and fastest) type of virtual machine is one with a Just-In-Time compiler, this means that the bytecode that the virtual machine interprets is also dynamically compiled into assembly and executed. This type of VM includes modern Javascript interpreters such as V8, Tracemonkey, and Squirellfish, as well as other VMs like the Hotspot Java virtual machine.

Now that we know where CPython is, and what the top of the totem pole looks like it's probably clear what Unladen Swallow is looking to accomplish, however there is a bit of prior art here that's worthy of taking a look. There is actually currently a JIT for CPython, named Psyco. Psyco is pretty commonly used to speed up numerical code, as that's what it's best at, but it can speed up most of the Python language. However, Psyco is extremely difficult to maintain and update. It only recently gained support for modern Python language features like generators, and it still only supports x86 CPUs. For these reasons the developers at Google chose to build their JIT rather than work to improve the existing solution (they also chose not to use one of the alternative Python VMs, I'll be discussing these in another post).

I just said that Unladen Swallow looked to build their own JIT, but that's not entirely true. The developers have chosen not to develop their own JIT (meaning their own assembly generator, and register allocator, and optimizer, and everything else that goes along with a JIT), they have instead chosen to utilize the LLVM (Low Level Virtual Machine) JIT for all the code generation. What this means is that instead of doing all the work I've alluded the devs can instead translate the CPython bytecode into LLVM IR (intermediate representation) and then use LLVM's existing JIT infrastructure to do some of the heavy lifting. This gives the devs more time to focus on the interesting work of how to optimize the Python language.

Now that I've layed out the background I'm going to dive into what exactly it is that Unladen Swallow does. Right now the CPython virtual machine looks something like this:

    for opcode in opcodes:
        if opcode == BINARY_ADD:
            x, y = POP(), POP()
            z = x + y
            PUSH(z)
        elif opcode == JUMP_ABSOLUTE:
            pc = OPARG()
        # ...

This is both hugely simplified and translated into a Pythonesque psuedocode, but hopefully it makes the point clear, right now the CPython VM runs through the opcodes and based on what the opcode is executes some C code. This is particularly inefficient because there is a fairly substantial overhead to actually doing the dispatch on the opcode. What Unladen Swallow does is count the number of times a given Python function is called (the heuristic is actually slightly more complicated than this, but it's a good approximation of what happens), and when it reaches 10000 (the same value the JVM uses) it stops to compile the function using LLVM. Here what it does is essentially unrolls the interpreter loop, into the LLVM IR. So if you had the bytecode:

    BINARY_ADD

Unladen Swallow would generate code like:

    x, y = POP(), POP()
    z = x + y
    PUSH(z)

This eliminates all of the overhead of the large loop in the interpreter. Unladen Swallow also performs a number of optimizations based on Python's semantics, but I'll be getting into those in another post, for now LLVM run it's optimizers, which can improve the generated code somewhat, and then CPython executes the generated function. Now whenever this function is called in the future the optimized, assembly version of it is called.

This concludes the introduction to Unladen Swallow. Hopefully you've learned something about the CPython VM, Unladen Swallow, or virtual machines in general. In future posts I'm going to be diving in to some of the optimizations Unladen Swallow does, as well as what other players are doing in this space (particularly PyPy).

November 03, 2009 11:14 AM

---

Greg Wilson

We’re Going to PyCon

The PyCon 2010 committee has just accepted our talk about Basie — we’ll see you in Atlanta in February!

November 03, 2009 11:02 AM

---

Simon Willison

Large Problems in Django, Mostly Solved: Search

November 03, 2009 10:42 AM

---

Catherine Devlin

A PyCon program committee volunteer reflects

The PyCon program committee has finished its work. All submissions have been reviewed, debated, argued on, and voted - often through several cycles. Emails accepting and declining talks have gone out.

I wanted to blog about my impressions as a program committee volunteer. Note that this is totally unofficial, and I'm not speaking on behalf of the committee, PyCon, etc.

It was wonderful

Just reviewing the talks was a great experience. Some of the talks were fun just to visualize; watching them will be even better. I learned lots about what is going on in the Python community. The program committee is a smart and fun crowd to work with, too.

It was horrible

The problem with a programming language that can do pretty much anything is that three days of scheduled talks are nowhere near enough to see everything that's going on. I wish we could have five days of talks, but there are too many people who wouldn't have the time or money for such a conference.

With room to accept fewer than half of our submissions, we had to turn away talks that would have been great. For instance, the one talk I most wanted to see - the proposal I would have walked barefoot to Atlanta for - got declined. What can you do? Often "pretty much everybody was pretty excited about this" talks had to be sacrificed for the sake of "virtually everybody was dying to see this" talks.

But wait, there's more

Fortunately, scheduled talks are only the tip of the PyCon iceberg. We have Lightning Talks, Open Spaces, and (new this year) poster board sessions! I hope all declined speakers will consider taking their material to one or more of those formats!

PyCon is going to be wonderful

I think we have the best crop of presentations we've ever had. If you can look through the list of accepted talks and not start making Atlanta travel plans, then you are already dead.

PyCon is going to be horrible

... because, with five simultaneous tracks packed with the very best of material, I promise you will face multiple can't-miss talks going on at the same time, all day, every day. The painful decisions of the program committee are really only a preview of the difficult decisions every attendee will have to make at the conference itself.

For 2011: increasing your chances

If you want to make your future PyCon proposal more appealing to the committee (making our decisions even harder - thanks a lot), here are some of the things I saw that helped talks make the cut.

• The basics: a clear talk description, orderly-looking outline, plausible-looking timings. If reviewers ask questions, answer them. Give every impression that you're prepared to put serious effort into your talk.


• Broad appeal. It's OK to present on specialty topics, of course, but if you can point out ways that even people outside the specialty will also want to see it, it will help.


• Unusual topic. Every year, there are some hot topics that everybody in the community seems to be talking about... and submitting talks on. Since we're not going to accept a dozen talks on any topic, no matter how hot, these talks need to prevail over a lot of competitors. On the other hand, if you've got a topic that makes the committee say, "HUH? Wow, I'd never heard of anything like that!", it really helps you stand out.


• We always get more intermediate-level submissions than for beginner or advanced, so the competition was fiercest there.


• What will attendees get from your talk that they couldn't get simply from reading the docs? Make sure we can tell.


• Evidence of preparation and skill. Some speakers had established reputations as skillful, engaging presenters; some provided links to their slide decks from earlier versions of their talks given at local groups or regional conferences; a few linked to actual recordings of earlier versions of their talks. Give your talk at a nearby usergroup, then convince one of your group members to volunteer for the program committee. :)


• Scratch the itch. When committee members say, "Ah, yes, I've been puzzled by that and dying for a proper explanation!" - or, "I personally understand it, but I see misunderstanding of it throughout the community and wish somebody would help clear it up", that is a big plus.


• Keep the Py in PyCon. If the topic is one of general IT interest - database technology or rich web client programming, for instance - then make sure to emphasize the Python angle of your talk. How do you work the problem from Python specifically? What do Python users need to know about the problem that they won't learn from materials aimed at the IT community overall?

Anyway, my personal thanks to everyone who submitted, and I really hope to see you all at PyCon!

November 03, 2009 09:37 AM

---

Rene Dudfield

Ich bin in Berlin

Berlin seems like a fun and laid back place. Arrived here the other day... haven't had much time to look around so far.

November 03, 2009 08:54 AM

---

PyPy Development

PyPy on RuPy 2009

Hello.

It's maybe a bit late to announce, but there will be PyPy talk at Rupy conference this weekend in Poznan. Precisely, I'll be talking mostly about PyPy's JIT and how to use it. Unfortunately the talk is on Saturday, at 8:30 in the morning.

Cheers,
fijal

November 03, 2009 08:38 AM

---

Steve Holden

Links for 2009-11-02 [del.icio.us]

• The Complete Guide to Google Wave
  Unofficial guide that seems quite helpful

November 03, 2009 08:00 AM

---

Eric Holscher

Large Problems in Django, Mostly Solved: Search

It's been a little over a year since I started doing Django development full-time, for one of them real jobs. Around that time, there were a few large problems in the community that hadn't been solved yet. They were kind of blemishes when you would talk to people about Django, and I'm happy that most of them have been solved.

This will be a series of posts that talk about the different big problems that have been solved, and how they have been addressed in the community.

Search

Search was probably the biggest annoyance for Django. It is something that every site needs, and something that just wasn't really happening in the Django community. 2008's Summer Of Code ended with djangosearch as a half-finished shell, that needed to be better architected; but it did show a good push in the realm of search.

Out of those ashes, comes an awesome solution to the search problem in Django. Haystack is something I am more familiar with (we use it in production at work), and is the brain child of the ever modest, house rocking Daniel Lindsley. It provides a number of Django patterns applied to search, which makes it easier to internalize.

Note: Another approach to search is available, which patches django's ORM. This uses the existing full-text search in your database.

Useful Haystack Patterns

Registration

The registration pattern of the admin allows you to unobtrusively make models searchable (including code you don't have access to). This allows you to register Django Comments as searchable for example, without forking the code base. This will look similar to the admin:

from haystack import site
site.register(Note, NoteIndex)

Search Querysets

Haystack provides an interface familiar to the Django ORM Queryset API. This gives you most of the commonly used functions from the ORM, but allowing you to use them on searches!

unfriendly_results = SearchQuerySet().exclude(content='hello').filter(content='world')
unfriendly_results.order_by('-pub_date')[:5]

It also gives you Search specific methods such as boost and facet.

Class Based Views

In 1.2, hopefully generic views will be class based. Haystack has an implementation of these as well. Like any other kind of class, it provides the easy ability to override functionality through subclassing.

This (simplified) example from the source shows how easy it is to provide extra context to a search view.

class FacetedSearchView(SearchView):
    def extra_context(self):
        extra = super(FacetedSearchView, self).extra_context()
        extra['facets'] = self.results.facet_counts()
        return extra

Pluggable Backends

Haystack currently supports three different search backends: Whoosh, Xapian, and Solr. With a publicly documented backend API, you can enjoy all of the power of the search engine of your choice, by providing a backend for it!

HAYSTACK_SEARCH_ENGINE = 'solr'

Documentation

A shining light in the Django world is the documentation. It is often talked about as being the biggest factor for how people learn Django and love it is the documentation. Haystack is another package with fantastic documentation. Here are a couple of little gems that really show the quality and thought that has been put into them:

• 7 step tutorial
• Debugging Haystack
• Best Practices
• Reference

The docs cover ways to improve your search and make it awesome, as well as just helping you get the software set up and running. The information is invaluable, and will help you make the search on your site really great!

Are you using Haystack?

If I'm preaching to the choir and you already use Haystack, there is a growing list of users that are using haystack. Daniel would love for you to contact him, and get yourself added to the list.

Did I miss anything?

Let me know what you love (or hate) about Haystack. I think it reuses a lot of the good patterns in Django, allowing people to take knowledge they already have, and apply it to a new problem domain easily. Is there anything that you don't like, or something that you love that I missed? Let me know in the comments!

November 03, 2009 04:01 AM

November 02, 2009

---

Simon Willison

Exploring Python

November 02, 2009 03:35 PM

---

S. Lott

Open Source in the News

Whitehouse.gov is publicly using open source tools.

November 02, 2009 02:50 PM

---

Reinout van Rees

Plone 3 theming - book review

November 02, 2009 02:28 PM

---

Greg Wilson

There’s No Such Thing As KeepItGoingCamp

There are lots of dating sites on the Internet, but many fewer devoted to keeping your marriage happy. Similarly, Toronto now has DemoCamp, Entrepreneurship 101, and a growing list of other events devoted to getting new ventures off the ground, but so far as I can tell, there’s nothing for technical types who want to know how to keep an established business going and growing.

One reason, I think, is that starting new things has a higher social status than being a conscientious gardener. Another is that the attitude and skills needed to start something are often quite different from those needed to keep something going: someone who’s good at turning a chance encounter into a phone number and a first date is often clueless when it comes to keeping a relationship going, and as many employers have found out the hard way, people who are good at landing jobs are often not good at actually doing them.

But even understanding it, I wish it weren’t so. I am running three projects that are going into their tenth, sixth, and second years respectively. The first two aren’t startups any more, and I sometimes wish there was somewhere I could go to talk to people who have small ventures that have been around long enough to be on their second logo and fifth or sixth development team.  Yes, there are business schools and Board of Trade seminars, but they’re not aimed at “small”. Maybe it’s just a matter of time: in idle moments, I imagine today’s DemoCamp crowd in their 70s, sitting in rocking chairs on the porch grumbling about how easy these young kids have it with their neural implants…  Here’s hoping.

November 02, 2009 11:05 AM

---

PyPy Development

Logging and nice graphs

Hi all,

This week I worked on improving the system we use for logging. Well, it was not really a "system" but rather a pile of hacks to measure in custom ways timings and counts and display them. So now, we have a system :-)

The system in question was integrated in the code for the GC and the JIT, which are two independent components as far as the source is concerned. However, we can now display a unified view. Here is for example pypy-c-jit running pystone for (only) 5000 iterations:

The top long bar represents time. The bottom shows two summaries of the total time taken by the various components, and also plays the role of a legend to understand the colors at the top. Shades of red are the GC, shades of green are the JIT.

Here is another picture, this time on pypy-c-jit running 10 iterations of richards:

We have to look more closely at various examples, but a few things immediately show up. One thing is that the GC is put under large pressure by the jit-tracing, jit-optimize and (to a lesser extent) the jit-backend components. So large in fact that the GC takes at least 60-70% of the time there. We will have to do something about it at some point. The other thing is that on richards (and it's likely generally the case), the jit-blackhole component takes a lot of time. "Blackholing" is the operation of recovering from a guard failure in the generated assembler, and falling back to the interpreter. So this is also something we will need to improve.

That's it! The images were generated with the following commands:

PYPYLOG=/tmp/log pypy-c-jit richards.py
python pypy/tool/logparser.py draw-time /tmp/log --mainwidth=8000 --output=filename.png

November 02, 2009 07:59 AM

---

Baiju M.

Congrats Noufal for PSF award!

Noufal Ibrahim, the main organizer or PyCON India 2009 received Python Software Foundation's Community Service award along with Barry Warsaw (Creator of Mailman). My hearty congratulation to Noufal Ibrahim and Barry Warsaw.

November 02, 2009 07:12 AM

---

Spyced

Cassandra hackfest and OSCON report

The best part of OSCON for me wasn't actually part of OSCON. The guys at Twitter put together a Cassandra hackfest on Wednesday night, with much awesomeness resulting. Thanks to Evan for organizing!

Stu Hood flew up from Rackspace's Virginia offices just for the night, which normally probably wouldn't have been worth it, but Cliff Moon, author of dynomite, showed up (thanks, Cliff!) and was able to give Stu a lot of pointers on implementing merkle trees. Cliff and I also had a good discussion with Jun Rao about hinted handoff--Cliff and Jun are not fans, and I tend to agree with them--and eventual consistency.

I also met David Pollack and got to talk a little about persistence for Goat Rodeo, and talked to a ton of people from Twitter and Digg. I think those two, with Rackspace and IBM Research, constituted the companies with more than one engineer attending. The rest was "long tail."

Back at OSCON, my Cassandra talk was standing room only. Slides:

My second talk is the one I would have preferred to give first, on "What Every Developer Should Know About Database Scalability". (I would have preferred to give it first so that I could have just said "come to my Cassandra talk for more details" instead of trying to cram that in at the end. But, it was in my proposal outline!) Slides: Other OSCON talks I liked (that have slides available):

• Gearman: Bringing the Power of Map/Reduce to Everyday Applications
• High Performance SQL with PostgreSQL [8.4]
• Linux Filesystem Performance for Databases (reiserfs blows everyone away for random writes, by a factor of > 2!?)
• Neo4j - The Benefits of Graph Databases
• Release Mismanagement: How to Alienate Users and Frustrate Developers

November 02, 2009 05:36 AM

---

Hans Nowak

eBay listings, part 3

More eBay listings… sorry for spamming… hopefully I can stop selling stuff soon. :-)

Today I listed a bunch of games:

• Riviera (GBA)
• Mario & Luigi Superstar Saga (GBA)
• Rayman (GBA)
• Mario Golf Advance Tour (GBA)
• Yggdra Union (GBA)
• Fire Emblem (GBA)
• Fire Emblem: The Sacred Stones (GBA)
• Civilization Revolution (Nintendo DS)
• Spore Creatures (Nintendo DS)
• Pokemon Pearl (Nintendo DS)
• Chameleon (PSP)

Some of these are cartridge only, others have boxes and manuals; check the descriptions.

(Also see part 2…)

November 02, 2009 02:43 AM

---

Kiwi PyCon

Kiwi PyCon Media Statement 3

Kiwi PyCon Media Statement 3

November 02, 2009 02:27 AM

---

V.S. Babu

Associate filetypes to VIM

This has to be the best VIM tip for Windows - Windows File Associations. For example:

assoc .otl=outliner
ftype outliner=c:\tools\vim\vim72\gvim.exe --remote-silent "%1"

November 02, 2009 01:42 AM

November 01, 2009

---

Aaron Brady

Mix Tape Era

I just read (uh, toward the end, skimmed) this awesome letter to Robert Smith by Amanda Palmer and, aside from giving me that claustrophobic omg-I-can’t-deal-with-nostalgia feeling, it made me think about pretty much the only illicit mix tape someone made for me.

It’s 2009, and I’m 26. When I was 14, and starting to appreciate good music it was (follow along) 1997, and MP3 was just about to kick off. But it hadn’t, or at least, it didn’t for those of us hanging out on IRC, with pay-by-the-minute 28.8Kbps modems.

Napster was two years away and back then you needed to find an FTP, upload enough to build a ratio to get the file you wanted, get randomly disconnected when a family member picked up the phone, reconnect, re-upload because the server forgot your ratio (you almost certainly had a dynamic IP) and finally download the track you wanted.

I had a 486 DX2/66, and I had to kill X, go to the console, and use mpg123 down sampling to 22Khz to acceptably play an MP3. To me, this experience gives you the same appreciation for music that thumbing through vinyl in a thrift shop and then getting up to flip the record at half time does.

Anyway, because the MP3 scene sucked, people with no money did things the old-fashioned way - going into basement record stores in Dublin city, and buying quasi-legal concert bootlegs, tape-to-taped for you “while-u-wait”. I don’t count this as my mix tape experience, because I went in knowing what I wanted.

Anyway x 2, back then, IRC was my life, and there was a muso on there called ANDY. ANDY, who in retrospect was not that cool, and who I got to see crying when someone he took to a party a few years later OD-ed (they were fine, btw) had the kind of music taste that seems like black magic when you’re 14, and they’re just a few years older.

ANDY liked Pixies and, though I have no idea how this even ended up happening, made me a mix of Pixies (Into the White, Hey), Frank Black (Men in Black), Sonic Youth (Teenage Riot) and Yo La Tengo (… not sure …).

This was not a life changing experience, at the time, and I think I listened to it a half dozen times and probably lost it when I cast out anything that was on magnetic cassette (much of which was inherited from my older brother, or were tape-to-tape copies of whole albums; nothing cool about that, kids). But, it did plant the seeds of US college music in my head.

Recently I was playing Rockband with some friends and Teenage Riot came on; I was vaguely aware that I knew this song, but not from where and I did an appalling job at keeping up with singing the lyrics, even with them printed in front of me. I think it’s good to rediscover old bands, Amanda Palmer clearly does.

Most of all, I think it’s a little cool to catch just the last little bit of mix tape culture, so I can say I didn’t just grow up in the era of MP3s.

November 01, 2009 11:22 PM

---

Sean Reifschneider

Setting up Pagination in Django

I've been using Django for some personal projects recently, and mostly I've been liking it just fine. However, I've had a bit of trouble with figuring out how to do some of the things I want to do. The documentation seems to lead to things like class documentation rather than examples of use, and the class documentation is really only a part of the story.

For example, one of the first things I wanted to implement on my photoblog was pagination. However, the documentation I could find was of fairly limited use, without creating a bunch of supplemental code myself. Which is what I did.

However, I then found a snippet on DjangoSnippets which lead me down the right path for doing the pagination much easier.

I've written up what I've found as an article on setting up pagination in Django.

November 01, 2009 10:09 PM

---

Hector Garcia

django-rbac

I just released my first version of a Role-Based Access Control system for permissions in Django.

Development code can be found in BitBucket: http://bitbucket.org/nabucosound/django-rbac/

The project's page is here

---

First of all, I would like to show some drawbacks of Django's current permission system:

• Permissions are tied directly to the User model from django.contrib.auth, so you cannot use any other existing model in your application.
• The task of mantaining this list of permissions in the current Django system is responsibility of a superuser or some other kind of centralized entity.
• You can certainly assign permissions to Group model instances, but all users in this group will share the same permissions.
• Last, but not least, until Django v1.2 will come and ticket #11010 implemented, the permission system is model-level -- it doesn't allow granular permissions (row-level), which means you can give a user authorization to do something based on all instances of a model class, but not to a single model instance (an object).

Many applications, and specially today's web applications -- which involve concepts as collaboration or content driven by the users -- need the flexibility to support delegation of permission granting to objects by other trusted agents. A clear example is a social networking site, where the users want to allow or deny access to their profiles or pictures, open or close their different communication channels like receiving friendship requests or private messages. django-rbac tries to champion this by introducing some key features from the Role-Based Access Control (RBAC) proposal. In this implementation users (subjects) are assigned different roles that, in turn, have (or not) privileges over objects. With this permission system, the owner of an object can give privileges to certain roles. For example, a user can grant access to other users trying to read some personal info only if they belong to, at least, one of the roles specified in the permission rule.

I initially developed the first version of this app for a social network, to give its users the ability to control who has privileges upon their profiles, photo albums, personal information, and such. If you are in a similar situation, you'll find that django-rbac suits perfect for your purposes. But, as long as a general-purpose access control is being implemented, even if you are building any other kind of application which needs this level of permission control, django-rbac will help you out. I think I have made it enough generic to match a wide range of use cases.

November 01, 2009 08:43 PM

---

Python 411 Podcast

Epiphany

Epiphany: The User Interface is the Programming Language, and the programming language is the user inerface. In the next 5-10 years, the Operating System of the future will take shape. Epiphany: it will be mobile and wearable.

November 01, 2009 06:42 PM

---

Ned Batchelder's blog

Magritte Mac sticker

I've seen clever decorations of Mac laptops incorporating the Apple logo before, but this Magritte-inspired sticker is one of the best. Their other stickers, for walls as well as laptops, are also good, with a nice dash of whimsy.

November 01, 2009 05:36 PM

• • RSS feed
  • Powered by Planet!
• Other Python Planets
  • Planet Jython
  • Planet IronPython
  • Planet Python Francophone
  • Planet Python Argentina
  • Planet Python Japan
• Python Libraries
  • OLPC
  • PySoy
  • SciPy
  • SymPy
  • Twisted
• Python/Web Planets
  • CherryPy
  • Django Community
  • Plone
  • Turbogears
  • Zope
• Other Languages
  • Haskell
  • Lisp
  • Parrot
  • Perl
  • Ruby
• Databases
  • MySQL
  • PostgreSQL
• Subscriptions
  • [OPML feed]
  • Aahz's Weblog
  • Aaron Brady
  • Abe Fettig
  • Adam Pletcher
  • Aftermarket Pipes
  • Alec Thomas
  • Alessandro Iob
  • Alex Gaynor
  • Alexander Artemenko
  • Alexandre Vassalotti
  • Ali Afshar
  • Alvaro Lopez Ortega
  • Anastasios Hatzis
  • Andre Roberge
  • Andrew Bennetts
  • Andrew Dalke
  • Andriy Drozdyuk
  • Andy Dustman
  • Andy Todd
  • Anna Martelli Ravenscroft
  • Anthony Baxter
  • Anton Belyaev
  • Armin Ronacher
  • Arthur Koziel
  • Arun Ravindran
  • Atul Varma -- Toolness
  • Baiju M.
  • Base-Art / Articles
  • Ben Bangert
  • Benjamin Peterson
  • Benjamin W. Smith
  • Benji York
  • Bertrand Mathieu
  • Bill Mill
  • BioPython News
  • Blended Technologies
  • BlueDynamics Alliance - Python Related
  • Brandon Rhodes
  • Brett Cannon
  • Brian Jones
  • Brian Jones
  • Brian Lloyd
  • Brian Ray
  • Calvin Spealman
  • Carl Trachte
  • Carlos Eduardo de Paula
  • Carlos de la Guardia
  • Catherine Devlin
  • Chad Cooper
  • Chad Whitacre
  • Checking and Sharing
  • Chris Leary
  • Chris McAvoy
  • Chris McDonough
  • Chris Miles
  • Chris Perkins
  • Christian Heimes
  • Christian Joergensen
  • Christian Scholz
  • Christopher Denter
  • Christopher Lenz
  • Christopher Perkins
  • Chuck Thier
  • Chui Tey
  • CodeSnipers
  • Collin Winter
  • Corey Goldberg
  • Cosmic Seriosity Balance
  • Courtney Ludwin
  • Cross-Platform Command Line Tools
  • Dalius Dobravolskas
  • Dan Jacob
  • Daniel Nouri
  • Dave Beazley
  • David Ascher
  • David Goodger
  • David Grant
  • David Janes
  • David Stanek
  • David Warnock
  • Davy Mitchell
  • Davy Wybiral
  • Dazza
  • Deadly Bloody Serious about Python
  • Denis Kurov
  • Dethe Elza
  • Diane Trout
  • Django Weblog
  • Djangocon
  • Doug Hellmann
  • Dougal Matthews
  • Dougma
  • Duncan McGreggor
  • Ed Taekema
  • Edward K. Ream
  • Efectos Especiales
  • Eli Bendersky
  • Enthought
  • Eric Florenzano
  • Eric Holscher
  • Eric Wu's Pythonfilter
  • Evan Fosmark
  • Fabio Zadrozny
  • Fazal Majid
  • Feet up! : dev/python
  • Flavio Coelho
  • Floris Bruynooghe
  • Frank Wierzbicki
  • Fredrik Lundh
  • Gael Varoquaux
  • Gary Bernhardt
  • Gary Wilson
  • Geert Vanderkelen
  • Georg Brandl
  • Gilad Raphaelli
  • Glenn Franxman
  • Glyph Lefkowitz
  • Go Deh
  • Graham Dumpleton
  • Grant Baillie
  • Greg Turnquist
  • Greg Wilson
  • Gregory Pinero
  • Grig Gheorghiu
  • Guido van Rossum
  • Gustavo Narea
  • Gustavo Niemeyer
  • Guyon Moree
  • Hanno Schlichting
  • Hans Nowak
  • Hector Garcia
  • Heikki Toivonen
  • Holger Krekel
  • Huy Nguyen
  • IPython0 blog
  • Ian Bicking
  • Ian Holsman
  • Ian Maurer
  • Ionel Cristian
  • IronPython-URLs
  • Ishan Chattopadhyaya (GSoC participant)
  • Isotoma
  • Ivan Krstic
  • Jack Diederich
  • James Gardner
  • James Tauber
  • Jarrod Millman
  • Jason Baker
  • Jason Diamond
  • Jason Hildebrand
  • Jean-Paul Calderone
  • Jeethu Rao
  • Jeff McNeil
  • Jeff Rush
  • Jeff Shell
  • Jeff Winkler
  • Jehiah Czebotar
  • Jehiah Czebotar
  • Jeremy Hylton
  • Jesse Noller
  • Jim Baker
  • Jkx@home
  • Johan Dahlin
  • John Cook
  • John Paulett
  • Jon Parise
  • Jonas Galvez
  • Jonathan Hartley
  • Jonathan LaCour
  • Jonathan LaCour
  • JotSite.com
  • Juan Rivas
  • Julien Anguenot
  • Juri Pakaste
  • Just a little Python
  • Kamon Ayeva
  • Katie Cunningham
  • Kay Schluehr
  • Kelly Yancey
  • Kenneth Reitz
  • Kerim Mansour
  • Kevin Dahlhausen
  • Kevin Dangoor
  • Keyphrene Dot Com
  • Kiwi PyCon
  • Krys Wilken
  • Kulbir Saini
  • Kumar McMillan
  • Kun Xi
  • Kun Xi
  • Laurent Szyster
  • Lawrence Oluyede
  • Lee Braiden
  • Leigh Honeywell
  • Lennart Regebro
  • Lesscode.org
  • Logilab
  • Low Kian Seong
  • Ludvig Ericson
  • Luke Plant
  • Malthe Borch
  • Malthe Borch
  • Marius Gedminas
  • Mark Dennehy
  • Mark Dufour
  • Mark McMahon
  • Mark Mruss
  • Mark Nottingham
  • Mark Paschal
  • Mark Ramm
  • Marko Samastur
  • Martin Blais
  • Mathieu Fenniak
  • Matt Goodall
  • Matt Harrison
  • Matt Kaufman
  • Matthew Rollings
  • Matthew Scott
  • Matthew Scott
  • Matthew Wilson
  • Max Ischenko
  • Max Khesin
  • Menno's Musings
  • Michael Bayer
  • Michael Crute
  • Michael Droettboom
  • Michael Hudson
  • Michael J.T. O'Kelly
  • Michael Schurter
  • Michael Sparks
  • Michael Watkins
  • Michal Kwiatkowski
  • Michele Simionato
  • Mike C. Fletcher
  • Mike Driscoll
  • Mike Naberezny
  • Mike Pirnat
  • Mikeal Rogers
  • Mikko Ohtamaa
  • Montreal Python User Group
  • Muharem Hrnjadovic
  • Nadav Samet
  • Nadia Alramli
  • Ned Batchelder's blog
  • Neil Blakey-Milner
  • Ng Pheng Siong
  • Nick Efford
  • Nicolas Evrard
  • Noah Gift
  • Nuxeo
  • Ondřej Čertík
  • Orestis Markou
  • Partecs
  • Patrice Neff
  • Patrick Roberts's Blog
  • Patrick Stinson
  • Paul Bissex
  • Paul Everitt
  • Paul Harrison
  • Paulo Nuin
  • Peter Bengtsson
  • Peter Eisentraut
  • Peter Harkins
  • Peter Hunt
  • Petro Verkhogliad
  • Phil Hassey
  • Philip Jenvey
  • Philipp von Weitershausen
  • Phillip J. Eby
  • Pradeep Gowda
  • PyAMF Blog
  • PyCon 2008 on YouTube
  • PyCon Podcast
  • PyCon UK News
  • PyPy Development
  • PyWorks Conference
  • Pylons News Feed
  • Python 411 Podcast
  • Python Advocacy
  • Python African Tour
  • Python Magazine
  • Python News
  • Python Open Mike
  • Python Secret Weblog
  • Python Software Foundation
  • Python User Groups
  • PythonThreads
  • Pythonology
  • Reinout van Rees
  • Rene Dudfield
  • Richard Jones' Log: Python
  • Robert Brewer
  • Robert Collins
  • Roberto Alsina
  • Roberto De Almeida
  • Robin Dunn
  • Robin Parmar
  • Rodrigo Araúj
  • Ryan Cox
  • Ryan Phillips
  • Ryan Tomayko
  • S. Lott
  • SDJournal
  • SPE Weblog
  • Scripting the web with Python
  • Sean McGrath
  • Sean Reifschneider
  • Sebastjan Trepca
  • Second p0st
  • Shalabh Chaturvedi
  • Shannon -jj Behrens
  • ShowMeDo
  • Shriphani Palakodety
  • Simon Belak
  • Simon Willison
  • Simon Wittber
  • Small Values of Cool
  • SnapLogic
  • SoCal Piggies
  • Speaking thru experience
  • Speno's Pythonic Avocado
  • Spyced
  • Stephen Ferg
  • Steve Holden
  • Steven Wilcox
  • Stian Soiland
  • Supervisord
  • Swaroop C H
  • Sylvain Hellegouarch
  • Tales of a Programming Hobo - Christopher Armstrong
  • Tarek Ziade
  • Technium Talks
  • Ted Leung
  • Tennessee Leeuwenburg
  • Terry Peppers
  • The Law Of Unintended Consequences
  • The Occasional Occurrence
  • The PyCon blog
  • The Python Papers
  • The Thiers
  • The Voidspace Techie Blog
  • Thomas Guest
  • Thomas Vander Stichele
  • Tim Golden
  • Tim Parkin
  • Titus Brown
  • Tobias Ivarsson
  • Todd Ogasawara
  • Troy Melhase
  • Tuukka Mustonen
  • Uwe Feldtmann
  • V.S. Babu
  • Valentino Volonghi
  • Victor Ng
  • VirtualVitriol
  • Viva La Chipperfish
  • Washington Times OpenSource
  • Wayne Witzel
  • Will McGugan
  • William's Journal
  • Wolfram Kriesing
  • Wyatt Baldwin
  • Yannick Gingras
  • Zachary Voase
  • europython.eu latest entries
  • it's getting better
  • ivan krstić · code culture
  • mrevelle's log
  • orbited
  • planet.python.org updates
  • To request addition or removal:
    e-mail planet at python.org (note, responses can take up to a few days)