Planet Python

Last update: May 16, 2012 08:47 AM

May 16, 2012

eGenix.com

eGenix pyOpenSSL Distribution 0.13.0-1.0.0j GA

eGenix is pleased to announce eGenix pyOpenSSL Distribution 0.13.0-1.0.0j for Python 2.4 - 2.7, with support for Windows, Linux and Mac OS X.

May 16, 2012 07:00 AM

PyCon

Apac PyCon 2012

Apac PyCon 2012 is here. Be sure to register for it at http://apac.pycon.org

 and come experience the wonderful talks from our keynotes and speakers at Singapore!

May 16, 2012 05:03 AM

May 15, 2012

Roberto Alsina

Nikola Plans

English only!

I have not stopped working on Nikola, my static site generator. Here are the plans:

1. Finish the theme installer (so you can get a theme from the site easily)
2. Implement a theme gallery on the site (same purpose)
3. Fix a couple of bugs
4. Update manual
5. Polish a few theme bits
6. Release version 3.x (new major number because it requires manual migration)

After that, I will push on projects Shoreham (hosted sites) and Smiljan (planet generator) and make them more public. Shoreham will become a real web app for those who don't want to have their own server. For free, hopefully!

Once I have that, I have no further feature ideas, really. So I need more people to start using it, and that means I have to start announcing it more.

So, stay tuned for version 3.x sometime next week.

Post-Nikola, I will do a rst2pdf release, and then will get back to work on a book.

May 15, 2012 10:05 PM

Tryton News

End of maintance for series 1.4

It makes now more than 2.5 years since the first release of series 1.4.
This ends the maintenance on this series.
To anyone who is still using it, it is highly recommended to upgrade to a more recent series.

May 15, 2012 08:56 PM

Jeet Sukumaran

Building and Installing SciPy, NumPy and PyMC on OS X 10.7 Lion

Site Section: 

• Computing

Keywords: 

• Python
• OS X
• SciPy
• Numpy
• PyMC

    export CC=clang
    export CXX=clang
    export FFLAGS=-ff2c
    export LDFLAGS="-arch x86_64 -Wall -undefined dynamic_lookup -bundle"
    export FFLAGS="-arch x86_64"

May 15, 2012 02:37 PM

John Cook

Machine Learning in Action

A couple months ago I briefly reviewed Machine Learning for Hackers by Drew Conway and John Myles White. Today I’m looking at Machine Learning in Action by Peter Harrington and comparing the two books.

Both books are about the same size and cover many of the same topics. One difference between the two books is choice of programming language: ML for Hackers uses R for its examples, ML in Action uses Python.

ML in Action doesn’t lean heavily on Python libraries. It mostly implements its algorithms from scratch, with a little help from NumPy for linear algebra, but it does not use ML libraries such as scikit-learn. It sometimes uses Matplotlib for plotting and uses Tkinter for building a simple GUI in one chapter. The final chapter introduces Hadoop and Amazon Web Services.

ML for Hackers is a little more of a general introduction to machine learning. ML in Action contains a brief introduction to machine learning in general, but quickly moves on to specific algorithms. ML for Hackers spends a good number of pages discussing data cleaning. ML in Action starts with clean data in order to spend more time on algorithms.

ML in Action takes 8 of the top 10 algorithms in machine learning (as selected by this paper) and organizes around these algorithms. (The two algorithms out of the top 1o that didn’t make it into ML in Action were PageRank, because it has been covered well elsewhere, and EM, because its explanation requires too much mathematics.) The algorithms come first in ML in Action, illustrations second. ML for Hackers puts more emphasis on its examples and reads a bit more like a story. ML in Action reads a little more like a reference book.

May 15, 2012 01:23 PM

Grig Gheorghiu

The correct way of using DynamoDB BatchWriteItem with boto

In my previous post I wrote about the advantages of using the BatchWriteItem functionality in DynamoDB. As it turns out, I was overly optimistic when I wrote my initial code: I only called the batch_write_item method of the layer2 module in boto once.

The problem with this approach is that many of the batched inserts can fail, and in practice this happens quite frequently, probably because of transient network errors. The correct approach is to inspect the response object returned by batch_write_item -- here is an example of such an object:


{'Responses': {'mytable': {'ConsumedCapacityUnits': 5.0}},
 'UnprocessedItems': {'mytable': [
{'PutRequest': {'Item': {'mykey': 'key1', 'myvalue': 'value1'}}},
{'PutRequest': {'Item': {'mykey': 'key2', 'myvalue': 'value2'}}},
{'PutRequest': {'Item': {'mykey': 'key3', 'myvalue': 'value3'}}}]}}

May 15, 2012 11:22 AM

Morten W Petersen

Python style & flexibility, tabs or spaces

I've been programming Python for a good while, and in the beginning I was very occupied with the style in which things are written.

I always advocated using_names_like_this for everything, I guess because it is easy to read and understand, and it also takes into account acronyms which should be uppercase, as these acronyms are also separated from other words, for_example_html_text.

However, over the years, mostly these last couple of years, naming conventions aren't that important any more. Python is a very flexible language, and one can for example create a function that returns an instance of a class, the class being decided by the invoked function.. With this flexibility, separating functions from classes is somewhat redundant IMO, and one might just as well do everything in lower-case separated by an underscore.

However, I'm not riding these arguments anymore, there are a number of different Python systems such as Zope, Django, Repoze, Archetypes, Plone etc. that use a myriad of different ways of naming things.

I think the most important thing is, and has always been, the proper use of tabs and spaces in Python files, as this is the thing that can get you and has real impact on the "flow" of the program.

I think there are a couple of times in my Python career that I've encountered bugs due to mixed and erroneous spacing, and at least one of those bugs was pretty tough to get, but it's been a good while since that one. I don't think much about spacing any more, Emacs does the right thing whether I'm in text or Python mode.

One snag that always seems to get me is the use of commas in complex schema definitions in Archetypes for example, but that's thankfully always an error that stops the entire system so it's easy to catch.

My argument? Naming conventions aren't that important because there will never be enough willpower and resources to make everything completely consistent in the Python ecosystem.. and if one is very preoccupied with naming conventions, maybe it is time to drink a little less coffee, stress a little less and focus on the important parts of a program. [:)

May 15, 2012 09:16 AM

Yaco

How to integrate forms in the Django admin site? django-form-admin

It is very common having to add some feature only for the super users in our website, and it is common that the site where we put this feature is the admin site. Normally we try to hide from the user that he is (programmatically) outside of the Django adiministration, to provide for a better user experience; so our view will have the same path prefix as the administration (/admin/), and the same styles.

If we use forms in these features, we have a layout problem, or mucho work with CSS, because Django renders the forms (as_p, as_ul, as_table) in a very different way compared to the admin site. The django-form-admin app is tailored to solve this problem.

To show the diferences in layout between a normal form and another that uses django-form-admin, we’ll show an example of a form to update the value of some cookies defined in the settings.

For this we will create the following view, in for /admin/edit-cookies/:

@permission_required('my_perm')
def edit_cookies(request):
    initial = {}
    data = None
    if request.method == 'POST':
        data = request.POST
    for cookie in settings.COOKIES_EDITABLES:
        initial[cookie] = request.COOKIES.get(cookie, None)
    form = ChangeCookie(settings.COOKIES_EDITABLES,
                                      initial=initial, data=data)
    if form.is_valid():
        messages.info(request, _('Added the cookies'))
        response = HttpResponseRedirect(reverse('edit_cookies'))
        form.save(response)
        return response
    return render_to_response('foo/edit_cookies.html',
                              {'form': form},
                              context_instance=RequestContext(request))

We now code a form, to create/modify/delete the cookies:

class ChangeCookie(forms.Form):

    def __init__(self, cookies, *args, **kwargs):
        for cookie in cookies:
            self.base_fields[cookie] = forms.CharField(required=False)
        super(ChangeCookie, self).__init__(*args, **kwargs)

    def save(self, response):
        for key, val in self.cleaned_data.items():
            if val:
                response.set_cookie(key, smart_str(val))
            else:
                response.delete_cookie(key)

And the template to be rendered by our view, edit_cookies.html:

{% extends "admin/base_site.html" %}
{% load i18n admin_static admin_modify %}
{% block extrahead %}
    {{ block.super }}
    {{ media }}
    {{ form.media }}
{% endblock %}
{% block extrastyle %}
    {{ block.super }}
    <link rel="stylesheet" type="text/css" href="{% static "admin/css/forms.css" %}" />
{% endblock %}
{% block coltype %}
    {% if ordered_objects %}colMS{% else %}colM{% endif %}
{% endblock %}
{% block breadcrumbs %}
{% endblock %}
{% block content %}
    <div id="content-main">
        <form action="." method="POST">
            {% csrf_token %}
            {{ form }}
            <div>
                <input type="submit" name="submit" value="{% trans "Update Cookies" %}"/>
            </div>
        </form>
    </div>
{% endblock %}

The end result is not very good, because Django renders the forms in a very different way in the admin site.

But if we install the django-form-admin application in out project and we add some like this in our form (there are many ways to do it: inheritance, delegation, implicit, explicit) the difference is more than considerable:

    def __unicode__(self):
        from formadmin.forms import as_django_admin
        return as_django_admin(self)

This app has only had a minimal change in the last year, so this is a stable version. No changes were needed to adapt it to Django 1.3 or Django 1.4.

I hope you like it.

Related Posts:

• PyPI and YacoPyPI y Yaco">PyPI and YacoPyPI y Yaco">PyPI and YacoPyPI y Yaco
• A simple and impossible query in djangoUna simple e imposible consulta en django">A simple and impossible query in djangoUna simple e imposible consulta en django">A simple and impossible query in djangoUna simple e imposible consulta en django
• Inline Editing and translating in DjangoEditando y traduciendo inline en Django">Inline Editing and translating in DjangoEditando y traduciendo inline en Django">Inline Editing and translating in DjangoEditando y traduciendo inline en Django

May 15, 2012 09:02 AM

Chris McDonough

Why I Like ZODB

It's not a state secret that I like ZODB . It's a very civilized way to store web application data. I'll try to enumerate some of the most important reasons I like ZODB here, and why I prefer it to other NoSQL systems and relational systems.

For the record, the stuff in this blog post is in the context of writing a web application. I don't mean it in the context of an OLAP system, or some data warehousing system. I mean it in the context of writing your typical web application, which needs to support fewer than a couple thousand requests per second, a small fraction of which are write requests.

Transactions

ZODB uses transactions. When you write to a ZODB database, you change a bunch of objects, then you commit the changes. Until you commit your changes, other threads and processes accessing the database won't see those changes.

I take transactions entirely for granted when writing an application. Wrapping a set of actions which mutate persistent data in a transaction makes a whole class of really hard problems disappear. Many existing NoSQL databases like MongoDB do not.

Any speed or feature benefit in using a non-transactional data store would just be lost in the noise of needing to cope with the loss of transactionality for anything except the most immense, purpose-built application (e.g. you're writing Twitter, or GitHub). If an application is anticipated to serve fewer than, say, 50 write requests per second or so, it's pretty foolish to even momentarily consider using a system without transactions. Even much busier systems can be engineered to use databases with transactions, albeit with lots of fancy coding.

Truth be told, I'm really not clever enough to write a system without transactions where I needed to have any level of confidence that I have the storage of inter-related data right. I'm also pretty sure I don't want to be that clever, and that a job that required me to be that clever would be a very long job indeed. I certainly wouldn't willingly reach into my toolbox and pick out a data storage without transactions for a run-of-the-mill, low-traffic web application.

ZODB gives me transactions, and I appreciate that.

Caching

The way ZODB operates is pretty simple. Any pickleable object created in memory can be persisted. It's persisted by attaching it (via ``__setattr__``) to any other persistent object. Once persisted, every object has its own identifier that can be used as a cache key.

Because the organization of data in the database is a function of the same data as it might otherwise be organized in memory, ZODB has a natural caching system that is simple and robust. Each persistent object, once loaded, remains in a per-thread memory cache until evicted. It's evicted when it hasn't been accessed in a while and RAM is needed to load a more recently accessed object into the cache, or when another thread or process has changed the object. There's very little cost associated with asking for the same set of objects over and over once that set of objects has been asked for initially.

If your working set is smaller than your available RAM, the way ZODB caches its objects effectively means that accessing an object loaded from ZODB is almost costless after the object is first loaded. That object won't be evicted from the in-memory cache until it changes. In such cases, your application will work at "RAM speed" rather than at "disk speed". If your working set is larger than available RAM, accessing the same set of objects over and over won't be costless, but if you ask for that set of objects often enough, and they don't change very often, and you have an appropriate amount of memory in the machine, they will almost never be evicted from the cache.

Because most requests in a typical web application are read requests (they do not mutate persistent data), this built-in caching is extremely effective in a real-world sense. You usually don't have to employ a third-party caching system to make pages render quickly. They just render quickly in the first place without degrading too much as load increases. There are certainly times you have to think harder about it, such as when you begin to have too much data in your working set to effectively fit into the cache, but often applications never reach this level of exposure, and when they do, the answer is often to just increase the memory in the system and the cache size. In the worst case scenario, you do what everyone else who doesn't use ZODB does: you use a global external cache to make lookup speeds acceptable. In ten years of ZODB use, I can count the number of times I've had to do this on one finger. These days, instead of using an external cache, I might just try to change ZODB instead and improve its caching.

Testability

Of the things I really like about ZODB, the one I like the most is the ability to write easily unit-testable code.

I like the majority of the tests I write to be unit tests. Note: unit tests. Not functional tests. Not integration tests. I just want to test the code I'm trying to test, not its integration with the rest of the system. Functional and integration tests are useful and important too, and you need them for any serious application, but you can get better coverage and a much faster set of tests if you use unit testing in the majority. I don't think most people know what the difference between these styles of testing mean. But if you do know, you really know, and you care.

I have a deep respect for the amount of effort put into making object-relational mappings work. SQLAlchemy and other such systems are well written and thoughtfully executed. However, I find it unappealing that every ORM system I've run across effectively requires that you write integration and/or functional tests to actually test the code in your application. These tests need the code to run against a real database. The test code actually causes data to be modified in that database. Between each test case, the database needs to be reset to a baseline state.

This, in practice, utterly blows. As a limitation, it seems to be, at least in part, a function of the query syntax exposed by the ORM. It's an awful hard syntax to mock out. To my knowledge, it's so hard that no one has even tried, and folks just cave and use a "real" database, and write all of their tests as functional tests, or at least they write all of the tests that come near the database as functional tests. Most real-world code comes near the database, so it's often diminishing returns to even attempt to discern which of the tests can be non-integration tests, and thus people tend to just use the same setup and teardown for all their tests, even the ones that don't come close to the database.

Unit tests run much, much, much faster than integration and functional tests. When I see blog posts where people are trying to parallelize their test runs across multiple machines because their test suite takes so long to run, I want to weep, because it's very likely that they'd get just as much of a sense of comfort from a set of unit tests that ran thousands of times faster with a few functional and integration tests thrown in for the sake of sanity. But they can't, because their toolchain doesn't really support it.

ZODB makes it very easy to write the majority of your tests as unit tests. Because the object graph is just a tree of Python objects, and because each of those objects can be instantiated without any particular root or parent, and because often the "query syntax" of ZODB is just plain old Python item or attribute access, you can often just write test code like this:

  class TestFile(unittest.TestCase):
      def _makeOne(self, stream, mimetype):
          from .. import File
          return File(stream, mimetype)

      def test_ctor_no_stream(self):
          inst = self._makeOne(None, None)
          self.assertEqual(inst.mimetype, 'application/octet-stream')

      def test_ctor_with_stream_mimetype_None(self):
          stream = StringIO.StringIO('abc')
          inst = self._makeOne(stream, None)
          self.assertEqual(inst.mimetype, 'application/octet-stream')
          fp = inst.blob.open('r')
          fp.seek(0)
          self.assertEqual(fp.read(), 'abc')

The above test tests an implementation of a ZODB object representing a file (using the ZODB "blob" functionality). The file object it's testing would be considered a "model" by most people used to "MVC" terminology. Model code is actually pretty easy to test, and I suspect that with careful factoring and stubbing it's possible to test most ORM model code without actually using a database connection.

Let's try something harder. The hardest code to test in any web application is view code. View code is the code that responds to an invocation of a particular URL within your system. It's the code that ties everything together: the model objects that represent persistent storage, the various functional subsystems of the application like the HTTP request, sessions, mailers and filesystems, etc. It's hard to test because it's "where the rubber meets the road". Consider the following Pyramid view function, which is taken from an application that uses ZODB:

  from myapp import File

  def add_file(context, request):
      appstruct = get_appstruct(request)
      name = appstruct['name']
      filedata = appstruct['file']
      stream = None
      filename = None
      if filedata:
          filename = filedata['filename']
          stream = filedata['fp']
          if stream:
              stream.seek(0)
          else:
              stream = None
      name = name or filename
      fileob = request.registry.content.create(File, stream)
      context[name] = fileob
      return HTTPFound(request.mgmt_path(fileob, '@@properties'))

The above view function accepts a context object (a ZODB object representing a "folder", in this case, which is just a container of other ZODB objects), and a request object. It returns a Response. Here's a test for the function in the case where there's no file data provided:

  import unittest
  from pyramid import testing

  class Test_add_file(unittest.TestCase):
      def test_no_filedata(self):
          from .. import add_file
          created = testing.DummyResource()
          context = testing.DummyResource()
          request = testing.DummyRequest()
          request.mgmt_path = lambda *arg: '/mgmt'
          request.registry.content = DummyContent(created)
          appstruct = {'name':'abc', 'file':None}
          request.appstruct = appstruct
          result = add_file(context, request)
          self.assertEqual(result.location, '/mgmt')
          self.assertEqual(context['abc'], created)

  class DummyContent(object):
      def __init__(self, result):
          self.result = result

      def create(self, *arg, **kw):
          return self.result

Note that the test creates "dummy" (aka stub) objects for the context, the request, and the object that is returned from the call to create. It asserts that the created object is added to the context under the name abc. And that's all it does. In the running application, when a new file object is created by the view, it is persisted. But in the test, no database setup is required because the "query API" is limited to a single call: __setitem__, which seats the object into its parent. We can mock this up without much of a problem. In this case, the DummyResource has a suitable __setitem__ already, so we didn't need to do any mocking (it was already done for us). This test will run in microseconds.

There are definitely far more complex cases, requiring more stubbing, such as code that uses an indexing and querying system like repoze.catalog to look up persistent objects efficiently by asking a centralized index for all objects with such-and-such attribute. In those cases, the "query API" is not nearly as simple. But it's still simple enough to mock up without ever requiring a "real" ZODB database connection. The tests get longer, and the mocking and stubbing code becomes more complex. But it's not hopeless, like it seems to be in ORM systems.

Comparable idiomatic ORM code would construct the file object the same way but would then tend to call e.g. add on a semimagical threadlocal "session" object. So you'd need to at least mock out the thread local session, or come up with some other context-sensitive way to get at the session without the thread-local. It would also need to ensure that the a file object with the same name didn't already exist in the database before adding it blindly, which would imply some sort of exists query. Something like this (I realize my syntax is likely terrible):

  from myapp import Session
  from myapp import File

  def add_file(request):
      appstruct = get_appstruct(request)
      name = appstruct['name']
      filedata = appstruct['file']
      stream = None
      filename = None
      if filedata:
          filename = filedata['filename']
          stream = filedata['fp']
          if stream:
              stream.seek(0)
          else:
              stream = None
      name = name or filename
      exists = Session.query(File).filter_by(name=name).one()
      if exists:
         Session.query(File).delete(name=name)
      fileob = request.registry.content.create(File, stream)
      Session.add(fileob)
      return HTTPFound(request.mgmt_path(fileob, '@@properties'))

A test is nowhere near as straightforward to write when the view looks like this. You've obtained a global Session object from an import that needs to either be mocked or a stub of it passed in specially. This is purely convention, and you could construct a system that passed the session in like the "context" in a ZODB app, so that's not really a deep concern. But still, the contract of the Session object is complex. It needs to support a query method that accepts an argument, the result of which needs to support both a filter_by and delete method. The filter_by method needs to return an object that has a one method, and so on. The session is the source of truth in this view, and so mutations done through it need to be reflected in later queries.

This example doesn't even take into account more common cases where one query depends on the result of another data-mutating query, or methods of the session like flush which add attributes to recently add -ed objects representing automatically computed primary keys and so on.

It's no wonder that no one bothers to try to mock it out, and just punts back to always testing functionally. When you test functionally, your test runs in milliseconds rather than microseconds. And that difference adds up across lots of tests. You get a lot of power from the ORM, especially the power to do very ad-hoc queries in a sort of stream-of-consciousness way which is very useful in highly dynamic, ill-defined web applications. But you're paying a price. And often you don't need the ad-hocness supplied by the query syntax. You know exactly what you're looking for and where to find it. ZODB lends itself well to such applications, and the complexity curve seems more adjustable on a per-view basis.

For what it's worth I'd love to be wrong about needing to always write functional tests when an ORM is used. It would mean I could write applications that use an ORM in a style that suits my historical application writing patterns, and in a style that supports very fast test suites. Let me know if you've tried and succeeded. In the meantime, I much prefer to write ZODB applications for testing purposes. Note that it's not just ORMs that have this issue; database bindings for other NoSQL databases have similar issues (e.g. PyMongo); their APIs are very complicated and are difficult to mock. Often the features you gain from that complexity is not worth the price you pay.

May 15, 2012 07:10 AM

ShiningPanda

Python & Java: a unified build process (2/4)

In our previous blog post dedicated to Python and Java, we saw how Maven can orchestrate a unified build process for these two languages.

But most of the time, all artifacts within a build should take the same version. It was not the case in the sample project of our previous blog post, so let's find a way to unify this.

For Java it's easy: JARs and WARs are using the version located in their respective POMs, 0.1 in this case:

  com.shiningpanda
  jsample
  0.1
  jar
  

  
  
    
      
        
          org.codehaus.mojo
          exec-maven-plugin
          
            
            
              ${project.version}
            
          
        
      
    
  

# Folder containing setup.py
root = os.path.dirname(os.path.abspath(__file__))
# Path to __version__ module
version_file = os.path.join(root, 'pysample', '__version__.py')
# Check if this is a source distribution.
# If not create the __version__ module containing the version
if not os.path.exists(os.path.join(root, 'PKG-INFO')):
    fd = codecs.open(version_file, 'w', 'utf-8')
    fd.write('version = %r\n' % os.getenv('VERSION', '?'))
    fd.close()
# Load version
exec(open(version_file).read())
# Setup
setup(
    name = 'pysample',
    version = version,
    packages = find_packages(),
)

os.getenv('VERSION', '?').replace('-SNAPSHOT', '.dev')

May 15, 2012 05:48 AM

Montreal Python User Group

Second Distutils2 Sprint Wrap-up

The second event in our series of Distutils2 sprints was again a success. We’ve managed to fix some interesting issues and we’ve gained some experience points at dealing with the black magic of the packaging arcane.

We would like to thank TP1 for hosting the sprint at their nice Downtown Montreal offices and also for the pizza. Pierre Paul, our host, wrote a longer post relating the event.

Stay tuned for upcoming announcements on Distutils2 sprints.

Special thanks to the sprinters:

• Julien Courteau
• Jonathan Fernandes
• Patrice Gauthier
• Mathieu Leduc-Hamel
• Pierre Paul Lefebvre
• Alex Parij
• Kim Pettersen

Stay tuned this week for the announcement of the next sprint.

Here’s a glimpse of patches being born:

Divine inspiration:

May 15, 2012 01:48 AM

New Room For The Django Workshop

Pythonistas

The last workshop in French for the winter 2012 season is this Wednesday. We wish to remind you that there is still plenty of places left, and, especially, that the room we have for the workshop is not SH-R810 as announced, but SH-2420, also in the Sherbrooke Pavillion of UQÀM.

Here are all the details:

Django : monter une application web en Python

• Date: Wednesday 16th of May, from 6:00 PM to 9:00 PM (please come at 5:30PM if you need help setting up your computer)
• Place: UQAM, Sherbrooke Building, 200 Sherbrooke West, room SH2420
• Sign up: on Eventbrite
• Workshop’s wiki page
• Workshop’s original post

May 15, 2012 12:48 AM

May 14, 2012

Daniel Greenfeld

10 reasons to go to DjangoCon Europe

You should go to DjangoCon Europe in lovely Zurich, Switzerland. Here are 10 reasons why:

May 14, 2012 07:30 PM

Doug Hellmann

cliff -- Command Line Interface Formulation Framework -- version 0.7

$ pip install cliff

May 14, 2012 06:50 PM

Kenneth Reitz

Be Cordial or Be on Your Way

Contributing to Open Source can be stressful.

By opening a Pull Request to a popular project, you're inviting the maintainers and all of their users to analyze and scrutinize your code. Often, they will.

Most of the time, the maintainers of the projects do their best to be kind. If they have feedback or criticism, it's generally positive. Unfortunately, this isn't always the case.

Every once in while, maintainers and community members will shun and insult a contributor's work. This is a perfect example of what you should never do.

What if the Pull Request in question was the person's first time ever contributing to a project? They could be scared away from the world of open source forever.

Instead of simply yelling at a potential contributor and causing a mess of negativity and stress; the maintainer should take the opportunity to educate the user. They should point the user to a guide that outlines what the proper protocol for his project is.

As a project maintainer, it's extremely important to be respectful to your contributors. They often take what you say very personally.

Reflect

Take some time to reflect. Remember why you're doing this in the first place. I write open source software because I love software and want to help make my world a better place.

Why are you? If you don't have answer, maybe you shouldn't be doing it. If you find yourself maintaining a project purely out of obligation, maybe you should be doing less.

• Don't be an asshole.
• Make your contributors feel welcome and appreciated.
• Always say thank you.

Before you tweet, comment on a pull request, or comment publically about a project, remember that it's often not a peice of code you're critiquing — it's a human being.

I don't have the energy or patience for non-constructive feedback. Be cordial and positive or be on your way.

May 14, 2012 10:00 AM

Duncan McGreggor

Twisted SSH: Rendering a Log-in Banner/MOTD in Conch

1. an interactive Python prompt was rendered, e.g., ":>>"
2. the banner was getting written to the terminal, and
3. the terminal screen refreshed with the prompt at the top

• twisted.conch.recvline.RecvLine.connectionMade calls t.c.recvline.RecvLine.initializeScreen
• t.c.recvline.RecvLine.initializeScreen does a terminal.reset, writes the prompt, and then switches to insert mode. But this is a red herring. Since something after initializeScreen is causing the problem, we really need to be asking "who's calling connectionMade?"
• t.c.manhole_ssh.TerminalSession.openShell is what kicks it off when it calls the transportFactory (which is really TerminalSessionTransport)
• openShell takes one parameter, proto -- this is very important :-)
• openShell instantiates TerminalSessionTransport
• TerminalSessionTransport does one more thing after calling the makeConnection method on an insults.ServerProtocol instance (the one I had tried overriding without success), and as such, this is the prime suspect for what was preventing the banner from being properly displayed: it calls  chainedProtocol.terminalProtocol.terminalSize
• chainedProtocol is an insults.ServerProtocol instance, and its terminalProtocol attribute is set when ServerProtocol.connectionMade is called.
• A quick check reveals that terminalProtocol is none other than the proto parameter passed to openShell.

May 14, 2012 10:39 AM

Invent with Python

“I Need Practice Programming”: 49 Ideas for Game Clones to Code

So you know a little bit about programming (perhaps you’ve read the free book, “Invent Your Own Computer Games with Python”, a free programming book for beginners whose author shamelessly plugs at every chance) but you want to get better at coding. You can’t seem to find any open source projects that are at your level or easy for new people to contribute to. You’ve gone through a few of the practice problems at Project Euler but you want to create something more substantial, or at least a cool thing you can show your friends. (Not that finding the 31337th prime number isn’t cool.)

Here’s a list of game clone ideas for you to implement. Each has a short description of the game, links to videos of the game, and descriptions of what kind of algorithms you’ll need to know in order to implement them. These games have been selected for their simplicity, so you don’t have to spend several weeks designing art, levels, scripted dialogue, or complicated AI. These are clones designed to be doable in roughly a weekend. A Mario or Zelda clone would be complicated to put together, but a Tetris or Asteroids clone would be doable in a weekend.

Orisinal Games:

The Orisinal website has a great collection of Flash games with very simple mechanics that can be copied. http://www.ferryhalim.com/orisinal/

I especially recommend Winter Bells, A Daily Cup of Tea, Bugs, and Hold the Rope!

The Wikipedia entry for video game clones also lists some ideas.

Games from “Invent Your Own Computer Games with Python” and “Making Games with Python & Pygame” books:

These games are described in these free Python programming books and their source code is available. However, you can make your own variants.

1. Dodger

Description: Several bad guys fall from the top of the screen, and the user must avoid them. The player can be controlled with the arrow keys or more directly with the mouse. The longer the player lasts without being hit, the higher the score.

Variations: Have enemies fall at different rates and be different sizes. Have enemies fall from more than one side of the game. Have power up pickups that grant invulnerability for a while, slow down bad guys, give the player a temporary “reverse bad guys” power, etc.

This game is covered in Chapter 20 of “Invent with Python”

Download Source: dodger.zip

2. Memory Puzzle

Description: A board full of overturned cards. There is a pair for each card. The player flips over two cards. If they match, then they stay overturned. Otherwise they flip back. The player needs to overturn all the cards in the fewest moves to win.

Variations: Provide “hints” in the form of four possible matching cards after the player flips the first one. Or, quickly overturn groups of cards at the beginning of the game.

This game is covered in Chapter 1 of “Making Games with Python & Pygame”

Download Python Source: memorypuzzle.py

3. Sliding Puzzle

Description: A 4×4 board of numbered tiles has one missing space and is randomly set up. To win the game, the player must slide tiles over to put the tiles back in order.

Variants: Instead of numbers, you can have a scrambled picture cut up into 4×4 tiles.

This game is covered in Chapter 4 of “Making Games with Python & Pygame”.

Download Python Source: slidepuzzle.py

4. Simon

Description: Four colored buttons light up in a specific pattern. After displaying the pattern, the player must repeat the pattern by clicking the buttons in proper order. The pattern gets longer each time the player completes the pattern. If the player presses a wrong button, the game ends.

Variant: A nine-button version can add challenge to this game (but more than that would probably just be tedious.)

This game is covered in Chapter 5 of “Making Games with Python & Pygame”.

Download Pyhton Source: simulate.py

5. Nibbles

Description: A worm or snake constantly moves around the board. The player controls the direction the “head” of the worm moves, and the worm must try to eat apples that randomly appear. Eating an apply causes the worm to grow in length. The game ends if the worm crashes into the edge of the board or into itself.

Variants: Add walls to the level, instead of just a blank rectangle. Add power ups that the worm can pick up. Add bad guys that move around the board that the worm must avoid. Have two worms that the player must control simultaenously. Tron (see below) is a two-player variant of this game.

This game is covered in Chapter 6 of “Making Games with Python & Pygame”.

Download Python Source: wormy.py

6. Tetris

Description: Shapes made up of four blocks fall from the top of the board. The player must rotate and place them to create full rows with no gaps. When a full row is made, the blocks in that row disappear and the blocks above it move down. The game ends if the board fills up.

Variant: Several Tetris variants are listed on Wikipedia. http://en.wikipedia.org/wiki/List_of_Tetris_variants

This game is covered in Chapter 7 of “Making Games with Python & Pygame”.

Download Python Source: tetromino.py

7. Katamari Damacy

Description: The original Katamari Damacy game was in a 3d world, but a 2d version is also easy to implement. The player controls a small object in a world of different-sized objects. Touching the smaller objects grows the player, touching the larger objects damages or shrinks the player. The player wins when they reach a certain size.

A flash version of 2D Katamari is available.

This game is covered in Chapter 8 of “Making Games with Python & Pygame”

Download Source: squirrel.zip

8. Sokoban

Description: The player is in a level with objects that need to be pushed over goals. The objects can only be pushed, they can’t be pulled. This game does require some effort to design levels for, but Sokoban levels have been designed by others and published on the web.

Variant: Add all sorts of level gimmicks: teleport tiles, conveyor belts, buttons that open doors/bridges, buttons that need an object left on them to keep a door open.

This game is covered in Chapter 9 of “Making Games with Python & Pygame”.

Download Source: starpusher.zip

9. Othello

Description: On a grid, a black and white player places tiles of their color on the board. The opponent’s tiles between the newly placed tile and that player’s existing tiles are flipped to become the color of the player’s tiles. The game ends when the board fills up and the player with the most tiles of their color wins.

Variant: Three player Othello with three different colors. Non-square boards.

This game is covered in Chapter 10 of “Making Games with Python & Pygame”.

Download Source: flippy.zip

10. Flood It

Description: A grid of six colors of tiles starts off randomly. The player can do a “flood fill” on the top left tile, changing the color of any adjacent tiles of thesame color. The player wins if they are able to make the entire board a single color within a certain number of moves.

Variants: Power ups gained when a certain tile is changed.

This game is covered in Chapter 10 of “Making Games with Python & Pygame”.

Download Source: inkspill.zip

11. Connect Four

Description: Two players of different colors drop their tokens on an upright board. The player to make four tokens in a row, column, or diagonal wins. Creating an AI for this requires a simple minimax algorithm.

Variant: Different board sizes. Walls inside the board that appear when the spaces beneath them are filled.

This game is covered in Chapter 10 of “Making Games with Python & Pygame”.

Download Source: fourinarow.zip

12. Bejeweled

Description: The board is filled with seven different types of jewels. The player can swap two adjacent jewels to form a three-in-a-row, causing the jewels to disappear and the jewels on top of them to fall down. Creating chain reactions gives bonus points.

Variant: Different power ups for matching a particular jewel. Be able to sometimes swap jewels that are not adjacent to each other. Timed games.

The original Bejeweled game and its sequels are at http://www.bejeweled.com/

This game is covered in Chapter 10 of “Making Games with Python & Pygame”.

Download Source: gemgem.zip

Board Games:

Board games are a good source for game clone ideas. A game like Monopoly has far too many rules to put together in a short time frame, but here’s a list of board games that have simple mechanics. Chess, Go, and Stratego may be too complicated to create an AI opponent, but in that case you can just make it a two-player game. These games don’t really have variants,

13. Mancala

YouTube video showing gameplay. Mancala rules

Description: A stone capture game where the board is made up of 12 pits and a “score pit” that the player tries to move their stones into. A simple minimax algorithm can be used by the AI.

Variants: Wikipedia has a list of “mancala games”.

Source code for Awale, a Mancala variant.

14. Tic-tac-toe

Wikipedia page explaining rules.

Description: Players put down their X or O symbol on a 3×3 board and try to get three in a row.

Variants: Using a 3x3x3 board for 3D Tic-tac-toe. Wikipedia has a list of variations.

15. Quarto

Quarto rules YouTube video explaining the rules

Description: Two players take turns setting one of the 16 pieces which is either: tall/short, light/dark, square/circular, and hollow/solid. The goal is to get four in a row of a common trait.

Variants: You can increase the board size and the number of types of pieces.

16. Abalone

Wikipedia page with game rules. YouTube video explaining the rules.

Description: Players move their marbles around a hexagonal board, trying to be the first to push six of the opponent’s marbles off the edge of the board.

17. Quoridor

YouTube video explaining the Quoridor rules

Description: Two players try to move their token to the other side of the board. On their turn, they can either move their token one space or place a wall on the board. A player cannot completely seal in the other player with a wall. An AI for this game may be too complex, but a two-player version should be simple to implement.

Variants: See Minotaurus, the next game.

18: Minotaurus

YouTube video showing gameplay.

Description: This game is essentially a more complex and multiplayer version of Quoridor, with a “Minotaur” monster added in that can attack players.

Variants: Add different level/wall designs instead of the standard board. Add teleports, or buttons that can activate doors and bridges.

19: Stratego

YouTube video explaining the rules and demonstrating gameplay. Wikipedia page explaining rules.

Description: Two players set up army units on the board and try to determine the strength of their opponent’s units. Disinformation is an important aspect of the game.

20: Blackjack

Rules of Blackjack

Description: Blackjack is a classic card game that is simple enough to implement a dealer AI for.

Variants: Variants of Blackjack are listed on the Wikipedia page.

21: Scrabble

YouTube video explaining the rules

Description: Player form words from letter tiles on a board. Rare letters are worth more points. Some spaces on the board give letter or word bonuses. You will need a dictionary file for this program, which you can download from http://wordlist.sourceforge.net/.

Variants: There are too many to list here. See the Wikipedia entry for Scrabble Variants.

22: Grid Lock / Traffic Jam

YouTube video showing gameplay.

Description: The player must slide a target car through an exit, but other cars are blocking the way. Cars can only be moved vertically or horizontally depending on their starting orientation. Level designs can be copied from existing games.

23: Yahtzee

Yahtzee rules explained.

Description: Dice rolling game where the players try to achieve specific patterns of rolls.

Variants: Variants are listed on the Wikipedia page.

24: Risk

YouTube video of Dicewars gameplay.

Description: Each territory has a certain number of armies which can be used to attack adjacent territories. The player can attack as often as they want, but conquering too many territories stretches out their troops so that the territories can be reclaimed easily. Additional armies are given based on conquered territories, so not expanding fast enough will also lead to losing. A straight forward AI is relatively easy to produce.

Variants: Dice Wars is a high-speed Flash game that is similar to Risk.

25: Checkers / Draughts

YouTube link of a Checkers game.

Description: A player moves their pieces diagonally on a board and tries to “jump” the opponent’s pieces.

Variants: Some variants are listed on the Wikipedia page for Draughts.

26: Chess

Description: Chess is a classic game, and the rules are explained on Wikipedia.

Variants: Some variants are listed on the Wikipedia page for Chess Variants.

27: Go

Rules explained YouTube video show

Description: Players take turns laying down stones and try to capture areas of the board. See the rules for full details. Even simple Go-playing AIs require deep levels of knowledge, but a two-player game is easy to create.

Action Games:

28: Asteroids

YouTube video showing gameplay

Description: The player rotates a ship to shoot asteroids, which break into two smaller asteroids when hit. The player must avoid being hit by the asteroids which slowly move around the screen. The player has no brakes, and can only slow or stop by using thrust in the opposite direction they are traveling.

Variants: Having different weapons and an occasional UFO that shoots directly at the player.

29: Space Invaders

YouTube video showing gameplay

Description: A few rows of enemies gradually makes they’re way down to the player. The player must shoot them all before they reach the bottom.

30: Tron

YouTube video showing gameplay

Description: Players control a constantly moving object that leaves a trail of walls behind it. The player who avoids crashing into a wall longest wins.

Variants:

31: Missile Command

YouTube video showing gameplay

Description: Missiles are shot up from the ground to hit falling meteors before they hit cities. The missiles must be timed so that they reach their target at the same time that the meteor is there.

Variants: See Rampart below. Different weapon types (the kind used in Scorched Earth) are also possible.

Python source code

32: Pong

YouTube video showing gameplay

Description: A tennis game where players bounce a ball passed the other.

Variants: Several of the same variations found in Arkanoid can be used in Pong. Obstacles can be placed on the map instead of just an open field.

33: Arkanoid

YouTube video showing gameplay

Description: The player controls a paddle that bounces a ball off of bricks in the level. The bricks break when the ball bounces off of them. The level is cleared when all the bricks are destroyed.

Variants: Power ups fall from smashed blocks, including: triple ball, longer paddle, ball breaks through bricks, a laser shoots out from the paddle.

Python source, another Python source, and another, and another.

34: Maze

Wikipedia entry on Maze Generation Algorithms

Description: Player runs through a maze to the exit. This is more of an exercise in writing maze-generation algorithms.

Variants: Teleports, buttons to control doors, keys to unlock doors, having multiple characters to move around that must work in sync to unblock each other’s paths.

Python source code, and another.

35: Scorched Earth / Worms / Gorillas / Angry Birds

YouTube video showing gameplay

Description: Players control tanks on a 2D hilly terrain and enter the numeric angle and velocity of a cannonball shot. The object is hit the other player’s tanks.

Variants: Angry Birds is a version of this game that adds a physics engine instead of hills. Different weapon types besides the standard cannonball can be added. Several UI improvements can be made over the original game (using the mouse to enter the angle and velocity, displaying the previous turn’s angle and velocity, etc.) Destructible terrain and being able to move the tanks adds a new dimension to the game.

36: Lunar Lander

YouTube video showing gameplay

Description: The player controls a ship that must gently land on a flat surface of the moon. The ship has limited fuel, and using the thrusters affects the momentum of the ship (much like Asteroids).

37: Snood / Bust-a-Move

YouTube video showing gameplay of Snood YouTube video showing gameplay of Bust-a-Move

Description: The top of the board is filled with different colored bubbles. The player must shoot bubbles from the bottom to form a set of three bubbles of the same color in a row to make them disappear. The ceiling lowers over time. The player wins if the board is cleared of bubbles, and loses if the bubbles reach the bottom.

Variants: This is a similar game to Bejeweled, and the power ups used in that game could be used in this one.

38: Fruit Ninja

YouTube video showing gameplay

Description: Objects are thrown up over the screen and the player must drag the mouse over them.

Variants: Bonuses for combos. Some objects cause the player to lose if they are touched.

39: Last Stand

Link to the original Flash game

Description: On each round, a wave of zombies attacks a barricade while the player shoots from behind it. Several shots are needed to kill a zombie and accuracy counts. When the zombies reach the barricade they begin to damage it. The player loses if the barricade is destroyed. After each round, the player can spend actions on finding new weapons, finding other survivors to help defend, or repairing the barricade.

Variants: Different zombie types (armored, fast moving-dog zombies, etc.) and weapons can be used (mines, grenades, traps).

40: Duck Hunt

YouTube video showing gameplay

Description: Ducks fly around the screen and the player must click on them to shoot them. The player has limited ammo.

Variants: The flight patterns of the ducks/objects can be changed.

41: Rampart

YouTube video showing gameplay

Description: The player alternates between building fortifications (to house cannons) and shooting at incoming ships. This game is similar to Missile Command, with a building mechanic added in.

Variants: Different enemy types (slow moving, armored ships or fast moving airplanes) and weapons can be added. Add different strength walls to build.

42: Bloxorz

YouTube video showing gameplay

Description: A puzzle game where the player must roll over a 2×1 brick to an exit point on the map. The brick cannot be moved off the edge of the board, and since it can only be flipped end over end and not slid around, the 2×1 nature restricts the types of moves it can make.

43: Dr. Mario

YouTube video showing gameplay

Description: A Tetris-like game where two-colored pills fall on different colored germs. Forming four in a row of the same color germ/pills causes them to disappear. The player wins when all the germs are cleared from the board, and loses if the pills fill up the board.

Variants: Similar to Puyo Puyo.

44: Kirby’s Avalanche / Puyo Puyo

YouTube video showing Kirby’s Avalanche gameplay Wikipedia entry for Puyo Puyo

Description: Essentially like a two-player Dr. Mario without the germs.

45: Fire ‘N’ Ice

YouTube video showing gameplay

Description: A very original but obscure puzzle game on the NES. The player controls a wizard who can make and unmake ice cubes, which need to fall on all the fire in a level to clear it. The ice can also be used as platforms, and individual blocks of ice can be pushed around. (As a platformer, making a clone of this might be a bit more involved. But the concept is original enough where I think it’d be worth the effort.)

46: Typespeed

YouTube video showing gameplay

Description: A typing game where words slowly move to the right side of the screen. The player must type the word to make them disappear. The player loses after enough words hit the right side of the screen.

47: Diner Dash

YouTube video showing gameplay

Description: A game where several different tasks in sequence must be managed simultaneously. Diner Dash has a restaurant theme, but other themes could be applied.

Variants: Usually there are ways to streamline tasks by doing them in a certain order (e.g. the player can carry meals for two tables at the same time).

48: Pipe Dream

YouTube video showing gameplay

Description: The player must put down different shaped pipes on the board. The pipes cannot be rotated or moved after placement, but the player does get to see the next several pipes that will be used. A little after the start of the game, water begins to flow through the pipes.

49: Zoop

YouTube video showing gameplay

Description: Colored bubbles begin to appear from four sides of the board. The player can assume the color of the bubbles, and then destroy bubbles of a similar color. The game ends if the bubbles fill up one side of the board.

May 14, 2012 05:21 AM

May 13, 2012

Kay Hayen

Nuitka Release 0.3.22

This is to inform you about the new stable release of Nuitka. Please see the page “What is Nuitka?”for clarification of what it is now and what it wants to be.

This release is a continuation of the trend of previous releases, and added more re-formulations of Python that lower the burden on code generation and optimizations.

It also improves Python3 support substantially. In fact this is the first release to not only run itself under Python3, but for Nuitka to compile itself with Nuitka under Python3, which previously only worked for Python2. For the common language subset, it’s quite fine now.

May 13, 2012 10:18 PM

Brett Cannon

My (very shallow) thoughts on Dart

Being the language nerd that I am, I actually find it fun to learn new programming languages. Now typically this is nothing more than me reading all of the official documentation and writing some toy examples that give me a very shallow, quick-and-dirty feel for a language. Since I have been involved in language design for nearly a decade (started participating on python-dev in June 2002) and have done toy examples now in 18 languages (17 actually still run; I have never bothered to get Forth to work again after a gforth change broke my code), this is actually usually enough for me to grasp the inspirations for a language and thus understand its essence.

At work I have been doing some JavaScript work for an internal Chrome extension and dashboard and so that led me to want to look into what Dart had to offer over JavaScript. I know the language is only at version 0.09 (and still changing weekly), but the fundamentals are there so I wanted to see what the general feel of the language is (and will continue to be).

I also know Dart is somewhat controversial for some people. Personally, I fall on the "competition is good" side of the argument, not the "OMG fragmentation" side. I want ECMAScript Harmony to still happen and give me a cleaner, tighter, more functional JavaScript, but that doesn't mean Dart doesn't have a place in the world as a cleaner OO language for the web. Besides, me thinking otherwise would make me a massive hypocrite as I began working on Python before it was cool (I feel like I need a hipster meme for that statement, but I digress) and I have worked hard to convert people to Python from other languages. Hell, I have tried to foster competition between the Python VMs to get them to push each other to perform better and be ever more interoperable. IOW I don't totally buy this fragmentation argument.

Going into learning Dart I knew who was involved with the language which is what will inherently define how a language feels. I knew Lars Bak of V8 helped design the language, which meant it would have some design restrictions put on it to make it have a damn fast VM. Josh Bloch has been helping to design Dart's library which meant some JDK feel to it. I also know Jim Hugunin is involved which should also help with the VM speed. So fast with an API designed like the JDK.

What did I find? A language with a damn fast VM and a standard library that felt like the JDK. =) Take OO as a Python programmer would expect (e.g. pure OO where everything is an object, not dogmatic OO like Java where everything has to be in an class definition), make types entirely optional for testing and tooling purposes but enough support to use interfaces and generics, and then toss in abilities based on what JavaScript allows and then you have a good idea of what Dart offers.

So, Dart has optional typing. In case you have not heard, Dart does not use type information at runtime for performance and only throws any form of fit if a type doesn't match what is specified unless you run in checked mode. If you do that then you get warnings about possible type issues. But Dart's type system is unsound so don't expect typing to catch every error that a more strict type system might even when you run in checked mode. Dart views types as helpful documentation and a way to help tools assist with things, period. I actually find it rather refreshing to have a language that treats types as just documentation since that is really what they are for the programmer (VMs can use it for performance, but it isn't required for good performance and type safety only saves you from a minor set of bugs which every Python programmer probably realizes eventually =).

But that's even if you bother with types! You can write all of your code without types and everything will run without issue. Even generics are optional, so you can declare a function accepts a List or List; Dart doesn't care either way and it alleviates covariance/contravariance headaches by not caring if you don't care either. It's actually rather nice to have non-library code be written quickly using dynamic typing and only add in the type information for library code where you care about what interface is expected. IOW I think Dart strike a nice balance with how it does typing and I actually feel fine using types when I know what I expect to accept in my own code that I don't expect anyone else to rely upon.

Dart is OO, not prototypical like JavaScript. It's single-inheritance, which I'm fine with. It does have interfaces as one would expect in a statically typed language, but it softens their expense by allowing one to define a default implementation of an interface. What this means is that the Map interface will also give you a HashMap instance if you call new Map(). I suspect they snagged the idea from Scala  where you have the Map class which hides HashMap from the user if you simply don't care about what Map implementation you use.


It does have a modicum of privacy by using a leading underscore for signaling something is private, much like Python. But the privacy is enforced at the library-level or is public, period. Every field automatically has a getter and setter defined for them, so there is no way to force a private field (which I think is a good thing since I find private privacy bloody annoying). I also like that getters and setters are directly supported by the language with automatic generation show you don't ever have to see a setSomething()/getSomething() function call just to read/write a field, but you can do something like Python's properties very easily.


The standard libraries are fine and just feel like the JDK. Things are very much LBYL rather than EAFP. I am willing to bet (although I have not tested this) that exceptions are a little expensive in Dart (since exceptions are hard to optimize) and so they would rather go the LBYL way. But they still went a little overboard in my opinion on some things (e.g. the list interface has a last() method instead of supporting negative indexes). But there is nothing there that is making me run away screaming.


One place I do think Dart could use some improvement is simplifying their constructor rules. Upfront Dart has some nice syntactic sugar for a construction where you directly specify how a constructor's arguments map to instance fields, avoiding having to declare the constructor parameters and then also write an assignment. OK, I like that.


Dart also has initializer lists which let you initialize final fields. OK, that's cool and a nice idea taken from C++.


Constructors are not inherited. OK, that's fine since you probably want to be explicit about how you tweak stuff. But there is an exception about the default, no-argument constructor calling the superclass' no-argument constructor. So while not technically inherited, it might as well be in that single instance. And all defined constructors will automatically call the default constructor, which if it isn't defined you must explicitly call a constructor somehow (probably in the initializer list of your constructor). Um, OK...

And you have named constructors. This gets you around from the lack of type-based method overloading for constructors. OK, I can go with that.

You also have constant constructors since fields can only be initialized to compile-constant values. Fine, that's for performance and determinism in instance creation, so I can grasp the desire for that.

And then you have factory constructors. OK, this is where I go "WTF people". This is so that you can have a constructor that actually doesn't create a new instance but instead can return something else other than a new instance (think of Python's __new__() or any of Java's static factory methods). But this lets you use the new keyword on a factory constructor instead of using a static method. And that to me seems unneeded.

So lets recap what constructor options we have. We have regular constructors, default and defined, which supports initialize lists. You have named constructors. There are constant constructors. And you also have factory constructors. If you don't count the default constructor as special that means Dart has four types of constructors. WTF!?! I realize that Java's FactoryFactoryOfFactories crap has probably spooked the crap out of the Dart designers, all the while having Java influences making them think they need the new keyword for anything that would return an instance of a class, but this seems a bit much. Dart's function definitions are rich enough to allow for optional arguments, etc. which would suggest that the typical constructor can do the job of named constructors with static methods picking up the slack where absolutely necessary where factory constructors are used. Maybe I'm missing something here, but I think they tried to design for everything that is bad about Java's constructor mess without stopping to think what their function definitions already buy them, all while making sure the new keyword was used.

Luckily that is the only bit of Dart that I found poorly designed. Everything else is reasonable and something any JavaScript programmer will be somewhat familiar with or quickly grasp.

Now as I said, I only did toy examples in Dart beyond reading the docs from beginning to end. If I had more time this weekend I may have done one more coding example that was more involved, but I ran out of time. But based on what I have read and what I learned, I am happy with Dart and would be content in using it for programming for the Internet. I would also be totally happy being asked to use it in a situation where others wanted to use types (e.g. I would be fine ditching Java for Dart if people really felt the need to hold on to their types).

May 13, 2012 10:11 PM

Mikko Ohtamaa

Never use hard tabs

As there seems to be some confusion when hard tab characters (ASCII code 9) are appropriate in source code files here is a rule:

1) Never use hard tabs

1. 1) Unless your source code is hard tab sensitive (only such format I know is Makefile)

Reasons not to use hard tabs

• Due to legacy, different text editors treat hard tabs different. UNIX text editors prefer hard tab is 8 spaces, Windows text editors and IDEs (Eclipse) prefer that a hard tab is 4 spaces.
• The hard tab length agreement between different text editors cannot be reached
• The hard tab length agreement between people cannot be reached
• Thus, hard tabs may break source code readability and editability if there is more than a single person editing the file. They will open the file in an editor with different tab settings, edit it and next time you open the file it is ruined and all indentations are wrong.
• This is even worse on white space sensitive languages (Python, CoffeeScript) as this might actually cause syntax errors or programming logic errors

However, you can avoid this problem in the first place if you do indentation using soft tabs (spaces) instead.

Even if you were the single person in the world editing the text file, even you might switch the text editor in some point and accidentally shoot yourself in the leg.

Using soft tabs for indentation and having no hard tabs should not be a problem because

• All text editors can convert tabs to spaces in fly, when editing the file. Please note me if there are commonly used editors, besides Windows Notepad, which doesn’t do it yet.
• Text editors usually have different settings to tab key length and indentation settings. The latter is what you really want to adjust.

Pseudo-arguments for using hard tabs

• It makes the file size smaller: you really care about those twenty bytes on our terabyte hard disks?
• This one I made up: spaces count toward the file size in web stuff, because visitors download the files. However if those bytes really matter you that much you should be using a minimizer in the first place.
• I like them arguments…: rationale not involved
• The change resistance in human nature

You might have a legacy software project having its legacy style guides. If the project big, e.g. Linux kernel, the switching cost may be very high and not affordable. However, even with this kind of codebase, you can gradually replace hard tabs away.

Style guides

• Python style guide recommends no hard tabs
• PHP style guide recommends no hard tabs
• Java style guide recommends no hard tabs
• CSS style guide recommends no hard tabs
• etc.

Text editors

If you are a text editor author, make sure your text editor ships with hard tabs turned off by default, especially for whitespace sensitive languages if you vary tab policy by file type.

Note that this blog post, and the situation, could have been avoided if

• All text editors would have sticked to soft tabs by default
• All text editors would have sticked to a hard tab is 8 spaces by default

But in some point (when?) someone (who?) decided to make our life little more complex.

Tools for managing hard tab policy in your software project

• Catch hard tabs in a git pre-commit hook
• Convert existing source code tree to use soft tabs (spaces) instead of hard tabs

 Subscribe to this blog in a reader Follow me on Twitter

May 13, 2012 12:16 PM

Andrew Dalke

Finding the MCSes for the ChEBI ontology

This is part 3 of a series on MCS:

1. MCS background
2. fmcs - find the MCS of a set of compounds
3. Finding the MCSes for the ChEBI ontology

The industrious folks at EBI have been developing ChEBI, which expands to "Chemical Entities of Biological Interest." Quoting Wikipedia, "[ChEBI] is a database and ontology of molecular entities focused on 'small' chemical compounds, that is part of the Open Biomedical Ontologies effort."

They define several distinct ontologies. One is a chemical structure ontology. For example, the identifier CHEBI:33567 contains catecholamine, and a few examples of catecholamines are hexoprenaline (CHEBI:37950), arbutamine (CHEBI:50580), L-isoprenaline (CHEBI:6257). In addition, catecholamine is a catechol (CHEBI:33566), which in turn is a benzenediol (CHEBI:33570), and so on. A group can have more than one parent; catecholamine is also a monoamine molecular messenger (CHEBI:25375).

The end result is a hierarchial structure. The bottom of the hierarchy are structures, and intermediate nodes are such that all children of the node have some common property.

Some of these common properties map directly to a common substructure. For example, CHEBI:33853 contains phenols, so every compound under that node has "one or more hydroxy groups attached to a benzene or other arene ring."

However, not all of them do. As Chepelev, Hastings, Ennis, Steinbeck, and Dumontier pointed out in "Self-organizing ontology of biochemically relevant small molecules", BMC Bioinformatics 2012, 13:3, the term "'ester' includes compounds that conform to C(=O)OC (i.e. carboxylic esters) and C(=S)OC patterns, among others."

Other cases can't even be represented as SMARTS. They give "bicyclic" as one such example.

Can I find the MCS of all structures in a node in the ontology?

I was curious to see if I could use their data set as a test of fmcs. If their intermediate nodes have a machine-readable way to tell if it's a purely substructure-based node, and if I could get the size information, then I could get all the structures underneath it, find the MCS, and compare my answer to theirs.

Alas, they don't have that annotation information. It's something they are working on, but I didn't get the impression that it's a high priority. (I don't see why it should, either.)

Still, it's an interesting thought - what if I were to generate the MCS for all nodes, and visualize the results somehow?

It took a bit longer than I thought, but I finally downloaded their ontology (in OBO format), parsed it, extracted the hierarchy, figured out the compounds in each node, tossed out the structures that RDKit couldn't parse, and the nodes which didn't have at least two remaining structures in them.

One that was done, I let my MCS algorithm at it. It took about 50 minutes to process. (Well, I had a 15 second timeout on the MCS. I've found that 15 seconds is usually good enough.)

I also developed a visualizer for the result, using Karen Schomburg's SMARTSviewer and Daylight's depictmatch.cgi

Oooh! More pictures!

Here's a snapshot of one of the successful cases, CHEBI:16648, which is dialkyl phosphate:

Most of the results aren't as clear-cut. For example, CHEBI:16389 contains the ubiquinones. I found the MCS:

which is nearly right, but the Wikipedia page for Coenzyme_Q10 ("Coenzyme Q₁₀, also known as ubiquinone, ...") shows a methyl attached to the top-most oxygen this SMARTS depiction. This is because CHEBI:18238 is a structure in the set which does not have that methyl attached!

It this methyl important? I don't know. I'm not a chemist, and this requires expertise I simply don't have.

An oopsie in the oxolanes?

What I do know is that there's a mistake in the oxolanes, CHEBI:26912. Wikipedia calls this tetrahydrofuran and says it's an 5-membered ring with the formula (CH2)4O. I would write it as the SMILES/SMARTS "O1CCCC1".

However, my search finds only "OCCCC"; it doesn't find the cycle. There shouldn't be a problem with this one so I investigated further, wondering if it was a bug. It ended up that acetylblasticidin S (CHEBI:2413) is considered an oxolane. A quick look at the structure though shows that it has no 5-membered ring.

I think that's an annotation error. BTW, I do not envy the job of annotator. There's a lot of data to review, and people like me end up pointing out the mistakes, not the huge amount of work to get all the other parts right.

Even more pictures... most of the ChEBI ontology!

Do you want to see the output of my full analysis? Do you have a lot of memory on your computer? If so, download fmcs_chebi.html.bz2. It's only 7.5 MB but it bzip2 uncompresses to 166 MB. Open fmcs_chebi.html in your browser, and have fun! (Note: I'll probably delete it after a month or so.)

BTW: the images are computed on-demand using servers from the University of Hamburg and from Daylight. I didn't want to show everything at once since that would put a huge demand on those servers. Instead, you'll need to press the "Toggle images" button in order to see the SMARTS and the graphical depiction of the matches.

Comments

If you have comments or questions, leave them here.

May 13, 2012 12:00 PM

fmcs - find the MCS of a set of compounds

1. MCS background
2. fmcs - find the MCS of a set of compounds
3. Finding the MCSes for the ChEBI ontology

My new MCS program is named "fmcs." It uses RDKit for the cheminformatics and is is available under the BSD 2-clause license. Many thanks to Roche for funding the project and making it available under a free license. Their hope and mine is that fmcs will be included someday as part of RDKit. For now, you can download it from the Bitbucket site. My hope is that people will fund me to continue developing the program.

Show me an example

I'll start with a set of 3669 compounds which I know have a benzotriazole core. I know this because that data set come from doing a substructure search. If you want to try this yourself, the SD file is part of the fmcs distribution.

% fmcs sample_files/benzotriazole.sdf --verbose
Loaded 3669 structures from sample_files/benzotriazole.sdf     
[#7]:1:[#7]:[#7]:[#6]:2:[#6]:[#6]:[#6]:[#6]:[#6]:1:2 9 atoms 10 bonds (complete search)
Total time 5.89 seconds: load 2.76 fragment 2.66 select 0.42 enumerate 0.06 (MCS found after 3.13)

Most people can't look at a SMARTS like "[#7]:1:[#7]:[#7]:[#6]:2:[#6]:[#6]:[#6]:[#6]:[#6]:1:2" and easily figure out what it means, so I'll use Karen Schomburg's excellent SMARTSviewer to render it graphically:

as well as RDKit's image renderer to show the match to the first 10 structures of that data file.

Alternate atom and bond comparisons

ignore atom and bond types

By default, the subgraph matches atoms by element and bonds by bond type. There are other options. The "--compare topology" option lets any atom match any other atom, and any bond match any other bond.

% fmcs sample_files/ar_clustered_3D_MM_3.sdf
[#6]-[#6]-[#6]-[#6]-[#6]-[#6]-[#6]-[#6]-[#6](-[#6]-[#6]-[#6]-[#6])-[#6] 14 atoms 13 bonds (complete search)
% fmcs sample_files/ar_clustered_3D_MM_3.sdf --compare topology
[*]~1~[*]~[*]~[*]~[*]~2~[*]~[*]~[*]~3~[*](~[*]~1~2)~[*]~[*]~[*]~1~[*]~[*]~[*]~[*]~1~3 17 atoms 20 bonds (complete search)
[c-2ec28d18-74736162:~/cvses/fmcs] dalke% 

That's very interesting. It looks like there's a common substructure, based on the topology, but not when using on the default match parameters. Why is this?

It's a matter of bond perception. Some of the rings found by the topology search are aromatic in some structures but not in others, and some of the bonds are double in one and single in others. I know I gave PubChem a SMARTS pattern to find those structures. I wonder how it ended up like it did.

Match atom types but ignore bond types

The "--compare topology" flag is a shortcut for "--atom-compare any --bond-compare any". You can chose different options for comparing atom types and bond type. For example, if you want to compare atoms by element and ignore bond types then you can do "--atom-compare elements --bond-compare any".

Coming up with a good example of when to use it is left to the student as an exercise. (Let me know the answer when you figure it out, so I can include it here.)

Bond modifiers

Chemists like rings. That's because rings are important. A problem with MCS is that sometimes it matches a long chain of atoms with a strange routing through a ring system. Chemists don't always like that.

If you're one of those people, use the "--ring-matches-ring-only" flag. This make ring atoms match only ring atoms and chain atoms only match chain atoms.

Even that might be too generous. Sometimes chemists really want to see a complete ring in the MCS, and not just a partial one. That is, if the MCS includes a bond which maps to a ring bond in the original structures, then the MCS bond must also be in a ring.

If that's what you want, use the "--complete-rings-only" option.

When I figure out good uses cases for these, I'll update the primary documentation. (I'm told that they are important, but I don't have a good example for you to understand why.)

All that, and more!

I'm still working on the documentation for the newest features, added during the last couple of weeks. You can hijack the "isotopes" atom matcher to define your own atom classes, and specify those classes through a tag in the SD file. Instead of showing the SMARTS as the result, you can see the fragment as SMILES, or you can save the results to an SD file.

Comments

Do you have any comments or questions?

May 13, 2012 12:00 PM

Lightning Fast Shop

Release 0.7.3

We just released LFS 0.7.3. This is a yet another bugfix release of the 0.7 branch.

May 13, 2012 11:46 AM

Release 0.6.16

We just released LFS 0.6.16. This is a yet another bugfix release of the 0.6 branch.

May 13, 2012 11:46 AM

• • 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]
  • 2degrees
  • A Little Bit of Python
  • A. Jesse Jiryu Davis
  • Aahz
  • Adam Pletcher
  • Adrián Deccico
  • Alec Munro
  • Alex Clark
  • Alex Gaynor
  • Alexander Artemenko
  • Alexander Limi
  • Alexandre Bourget
  • Alexandre Conrad
  • Alexandre Vassalotti
  • Ali Afshar
  • Anastasios Hatzis
  • Anatoly Techtonik
  • Andre Roberge
  • Andrew Dalke
  • Andriy Drozdyuk
  • Andy Dustman
  • Andy Todd
  • Anna Martelli Ravenscroft
  • Anthony Baxter
  • Anton Belyaev
  • Anton Bobrov
  • Armin Ronacher
  • Arthur Koziel
  • Ashish Vidyarthi
  • Ashley Camba
  • Atamert Olcgen
  • Atul Varma -- Toolness
  • Audrey Roy
  • Baiju Muthukadan
  • Balthazar Rouberol
  • Barbara Shaurette
  • Barry Warsaw
  • Ben Bangert
  • Ben Bass
  • Benjamin Peterson
  • Benjamin W. Smith
  • Benji York
  • Bertrand Mathieu
  • Bill Mill
  • BioPython News
  • Bit of Cheese
  • Björn Tillenius
  • Blended Technologies
  • BlueBream
  • BlueDynamics Alliance
  • Bojan Mihelac
  • Brandon Rhodes
  • Brett Cannon
  • Brian Curtin
  • Brian Harring
  • Brian Jones
  • Brian Jones
  • Bryce Verdier
  • Caktus Consulting Group
  • Calvin Spealman
  • Carl Trachte
  • Carlos Eduardo de Paula
  • Carlos de la Guardia
  • Casey Duncan
  • Catherine Devlin
  • Chad Cooper
  • Chad Whitacre
  • Checking and Sharing
  • Chris Hager
  • Chris Leary
  • Chris McAvoy
  • Chris McDonough
  • Chris Miles
  • Chris Miller
  • Chris Perkins
  • Christian Heimes
  • Christian Joergensen
  • Christian Scholz
  • Christopher Denter
  • Christopher Lenz
  • Christopher Perkins
  • Chuck Thier
  • Chui Tey
  • Cloudnumbers
  • CodeSnipers
  • Collin Winter
  • Corey Goldberg
  • Cormoran Project
  • Cosmic Seriosity Balance
  • Craig Kerstiens
  • Creative Commons
  • Cross-Platform Command Line Tools
  • CubicWeb
  • Dalius Dobravolskas
  • Dallas Fort Worth Pythoneers
  • Dan Crosta
  • Daniel Brown
  • Daniel Greenfeld
  • Daniel Nouri
  • Dariusz Suchojad
  • Dave Beazley
  • David Ascher
  • David Goodger
  • David Grant
  • David J C Beach
  • David Janes
  • David Malcolm
  • David Stanek
  • David Winterbottom
  • Davy Mitchell
  • Davy Wybiral
  • Dazza
  • DeGizmo
  • Denis Kurov
  • Derrick Petzold
  • Dethe Elza
  • Diane Trout
  • Django Weblog
  • Djangocon
  • Djangofeed
  • Doug Hellmann
  • Doug Latornell
  • Dougal Matthews
  • Douglas Napoleone
  • Duncan McGreggor
  • EasyGUI
  • Ed Crewe
  • Ed Taekema
  • Edward K. Ream
  • Eli Bendersky
  • Enthought
  • Eric Florenzano
  • Eric Holscher
  • Eric Wu's Pythonfilter
  • EuroPython
  • Evan Fosmark
  • Fabio Zadrozny
  • Fazal Majid
  • Flavio Coelho
  • Floris Bruynooghe
  • Francisco Souza
  • Frank Wierzbicki
  • François Marier
  • Fredrik Håård's Blaag
  • Fredrik Lundh
  • From Python Import Podcast
  • Gael Varoquaux
  • Gary Bernhardt
  • Gary Wilson
  • Geek Scrap
  • Geert Vanderkelen
  • Gene Campbell
  • Georg Brandl
  • Gilad Raphaelli
  • Glenn Franxman
  • Glyph Lefkowitz
  • Go Deh
  • Godson Gera
  • Gonçalo Margalho
  • Graham Dumpleton
  • Gramps
  • Grant Baillie
  • Greg Taylor
  • Greg Turnquist
  • Greg Wilson
  • Gregory Pinero
  • Grig Gheorghiu
  • Guido van Rossum
  • Gustavo Narea
  • Gustavo Niemeyer
  • Guyon Moree
  • Gökhan Sever
  • Hanno Schlichting
  • Hans Nowak
  • Hany Fahim
  • Harrison Erd
  • Hector Garcia
  • Heikki Toivonen
  • Hilary Mason
  • Holger Krekel
  • Huy Nguyen
  • Hynek Schlawack
  • IPython0 blog
  • Ian Bicking
  • Ian Ozsvald
  • Ilian Iliev
  • Imaginary Landscape
  • Invent with Python
  • Ionel Cristian
  • Iraj Jelodari
  • IronPython-URLs
  • Ishan Chattopadhyaya
  • Isotoma
  • Ivan Krstic
  • Ivan Krstic
  • Jack Diederich
  • Jacob Perkins
  • Jaime Buelta
  • James Polera
  • James Tauber
  • Jared Forsyth
  • Jarrod Millman
  • Jason Baker
  • Jason Hildebrand
  • Jason Webb
  • Jean-Paul Calderone
  • Jeet Sukumaran
  • Jeethu Rao
  • Jeff Hinrichs
  • Jeff McNeil
  • Jeff Rush
  • Jeff Shell
  • Jeff Winkler
  • Jeremy Hylton
  • Jesse Noller
  • Jim Baker
  • Jim Fulton
  • Jim Hughes
  • Joe Abbate
  • Johan Dahlin
  • John Anderson
  • John Burns
  • John Cook
  • John Paulett
  • Jon Parise
  • Jonathan Ellis
  • Jonathan Hartley
  • Jonathan LaCour
  • Jonathan LaCour
  • Jonathan Street
  • Juan Rivas
  • Juho Vepsäläinen
  • Julien Anguenot
  • Julien Palard
  • Juri Pakaste
  • Just a little Python
  • Kai Diefenbach
  • Kai Lautaportti
  • Kamon Ayeva
  • Katie Cunningham
  • Kay Hayen
  • Kay Schluehr
  • Kelly Yancey
  • Kenneth Reitz
  • Kenneth Reitz
  • Kevin Dahlhausen
  • Kevin Dangoor
  • Kiwi PyCon
  • Konrad Delong
  • Kristján Valur
  • Kriti Godey
  • Krys Wilken
  • Kulbir Saini
  • Kumar McMillan
  • Kun Xi
  • Kun Xi
  • Laurent Luce
  • Laurent Szyster
  • Lawrence Oluyede
  • Lee Braiden
  • Leigh Honeywell
  • Lennart Regebro
  • Leonhard Vogt
  • Lesscode.org
  • Lightning Fast CMS
  • Lightning Fast Shop
  • Lion Kimbro
  • Lionel Tan
  • Logilab
  • Low Kian Seong
  • Ludovico Fischer
  • Ludvig Ericson
  • Luke Macken
  • Luke Plant
  • Maciej Fijalkowsk
  • Malthe Borch
  • Malthe Borch
  • Manuel de la Pena Saenz
  • Marc Garcia
  • Marcin Kuźmiński
  • Marcus Whybrow
  • Mario Boikov
  • Marius Gedminas
  • Mark Dennehy
  • Mark Dufour
  • Mark McMahon
  • Mark Mruss
  • Mark Nottingham
  • Mark Paschal
  • Mark Ramm
  • Marko Samastur
  • Martijn Faassen
  • Martin Blais
  • Mathieu Fenniak
  • Mathieu Virbel
  • Matt Goodall
  • Matt Harrison
  • Matt Wilkes
  • Matthew Rollings
  • Matthew Scott
  • Matthew Scott
  • Matthew Wilson
  • Mattias Brändström
  • Max Ischenko
  • Max Khesin
  • Menno's Musings
  • Michael Bayer
  • Michael Crute
  • Michael Droettboom
  • Michael Foord
  • Michael Hudson
  • Michael J.T. O'Kelly
  • Michael Nelson
  • Michael Schurter
  • Michael Sparks
  • Michael Watkins
  • Michal Kwiatkowski
  • Michał Domański
  • Michele Simionato
  • Mike C. Fletcher
  • Mike Driscoll
  • Mike Müller
  • Mike Naberezny
  • Mike Pirnat
  • Mikeal Rogers
  • Mikko Ohtamaa
  • Mitch Chapman
  • Mitchell Garnaat
  • Montreal Python User Group
  • Morten W Petersen
  • Mozilla Web Development
  • Muharem Hrnjadovic
  • Nadav Samet
  • Nadia Alramli
  • Ned Batchelder
  • Neil Schemenauer
  • Ng Pheng Siong
  • Nicholas Piël
  • Nick Coghlan
  • Nick Craig-Wood
  • Nick Efford
  • Nicolas Dumazet
  • Nicolas Evrard
  • Nicolas Paris
  • Nikhil Gopal
  • Noah Gift
  • Nuxeo
  • Omaha Python Users Group
  • Omar Abo-Namous
  • Ondřej Čertík
  • OpenHatch Python posts
  • Orbited
  • Orestis Markou
  • Partecs
  • Patrice Neff
  • Patricio Paez
  • Patrick Stinson
  • Paul Bissex
  • Paul Everitt
  • Paul Harrison
  • Paul Redman
  • Paulo Nuin
  • Pedro Kroger
  • Pedro Lima
  • Pete Hunt
  • Peter Bengtsson
  • Peter Eisentraut
  • Peter Halliday
  • Peter Harkins
  • Peter Hoffmann
  • Peter Parente
  • Petro Verkhogliad
  • Phil Hassey
  • Philip Jenvey
  • Philipp von Weitershausen
  • Philippe Normand
  • Phillip J. Eby
  • Phillip Pearson - Second p0st
  • Pietro Abate
  • Pradeep Gowda
  • Praveen Gollakota
  • PyAMF Blog
  • PyCharm
  • PyCon
  • PyCon 2008 on YouTube
  • PyCon Australia
  • PyCon Australia 2012 and 2013
  • PyCon Podcast
  • PyLadies
  • PyPy Development
  • PyTexas
  • Pylons News Feed
  • Python 4 Kids
  • Python 411 Podcast
  • Python Advocacy
  • Python African Tour
  • Python Diary
  • Python Insider
  • Python News
  • Python Open Mike
  • Python Software Foundation
  • Python Sprints
  • Python Testing Cookbook
  • Python User Groups
  • PythonThreads
  • Pythonology
  • Péter Szabó
  • R David Murray
  • Ralph Bean
  • Ralph Heinkel
  • Ram Rachum
  • Ramana
  • Randell Benavidez
  • Raymond Hettinger
  • Reinout van Rees
  • Rene Dudfield
  • Richard Jones
  • Richard Tew
  • Rob Cakebread
  • Rob Galanakis
  • Rob Golding
  • Rob Miller
  • Robert Brewer
  • Robert Collins
  • Robert Lujo
  • Roberto Alsina
  • Robin Dunn
  • Robin Parmar
  • Roche Compaan
  • Rocky Burt
  • Rodrigo Araúj
  • Rok Garbas
  • Ruslan Spivak
  • Ryan Cox
  • Ryan Tomayko
  • S. Lott
  • SDJournal
  • SPE Weblog
  • Salman Haq
  • Samuel Sutch
  • Sandro Tosi
  • Scripting the web with Python
  • Sean McGrath
  • Sean Reifschneider
  • Senthil Kumaran
  • Shannon -jj Behrens
  • ShiningPanda
  • Shriphani Palakodety
  • Simeon Franklin
  • Simon
  • Simon Brunning
  • Simon Willison
  • Simon Wittber
  • Speno's Pythonic Avocado
  • SpringSource
  • Spyder IDE
  • Stefan Scherfke
  • Stein Magnus Jodal
  • Stephen Ferg
  • Steve Holden
  • Steven Klass
  • Steven Kryskalla
  • Steven Wilcox
  • Stijn Debrouwere
  • Swaroop C H
  • SwiftStack
  • Sylvain Hellegouarch
  • Tarek Ziade
  • Ted Leung
  • Ted Nyman
  • Teemu Harju
  • Tennessee Leeuwenburg
  • Terry Jones
  • Terry Peppers
  • The Artificial Intelligence Cookbook
  • The Blagin' Wraith
  • The Monkey Project
  • The Occasional Occurrence
  • The Parcon Blog
  • The Python Papers
  • Thomas Guest
  • Thomas Vander Stichele
  • Thomi Richards
  • Tim Gilbert
  • Tim Golden
  • Tim Knapp
  • Tim Lesher
  • Tim Parkin
  • Titus Brown
  • Tobias Ivarsson
  • Tom Christie
  • Tomer Filiba
  • Tony Breyal
  • Torsten Engelbrecht
  • Toshio Kuratomi
  • Travis Oliphant
  • Troy Melhase
  • Tryton News
  • Turnkey Linux
  • Twisted Matrix Labs
  • Uche Ogbuji
  • United Coders
  • V.S. Babu
  • Vern Ceder
  • Vinay Sajip
  • Vinay Sajip (Logging)
  • Virgil Dupras
  • Viva La Chipperfish
  • Wallix
  • Washington Times OpenSource
  • Wayne Witzel
  • Wes Mason
  • Wesley Chun
  • Will Kahn-Greene
  • Will McGugan
  • Will Pierce
  • William Reade
  • William's Journal
  • Wingware
  • Wolfram Kriesing
  • Wyatt Baldwin
  • Xavier Spriet
  • Yaco
  • Yaniv Aknin
  • Yannick Gingras
  • Yuval Greenfield
  • Zachary Voase
  • Zeth
  • codeboje
  • eGenix.com
  • nl-project
  • planet.python.org updates
  • wiredobjects
  • Éric Araujo
  • To request addition or removal:
    e-mail planet at python.org (note, responses can take up to a few days)