Posts about python (old posts, page 31)

2010-03-24 17:27

The day we saw the dinosaur (an Ada Lovelace Day story)

Today, March 24th is Ada Lovelace day, a day of blogging to celebrate the achievements of women in technology and science.. I am taking the liberty to tag this as python so it appears in the right planets, but that's just to promote Ada Lovelace day. Sorry 'bout that.

I will write about the only person who ever taught me programming, Claudia. I was young, so the earth was still lukewarm, the day we saw the dinosaur.

I was just a green sophomore in the School of Chemical Engineering where, paradoxically I would never take a chemistry class, being an applied math student and all that, and at the time "personal computers" were a novelty, a toy of the upper middle class.

We had spent the first two months of the semester learning how to program the obvious way: writing assembler for a fictional machine on paper by hand, when Claudia broke the news, we were going to see a real computer.

No, not a PC, not even an XT, but a real computer, the one real computer in all the university, and you could hear the type switching to bold as she spoke about it. Sadly it was not as real as the one at the research facility (A MiniVAX!) but it was a real enough PDP.

We would not be allowed to actually use it until the following year, but ... well, it was still something special.

I had been programming for years, even for a year before I saw my first (seriosuly not real) computer, I had followed BASIC programs in my head for days, imagining the space invaders float on the screen of my mind, and stepped into writing machine code inside REM statements in my Timex Sinclair 1000 onto the luxury of a C64, but never noone had taught me anything.

Our small class (maybe 10 students) spent endless hours doing things like traverse a matrix, first by rows, thn by columns, then in a spiral from the top-left, writing programs that followed our endless source of algorithms, the numerical solutions guide.

First assembler, then Fortran, we learned.

She was my Mr. Miyagi, I was a heterosexual Ralph Macchio, and I figured out the most important thing about programming: I was awful at it.

Over the next 20 years that situation has been slowly improving, but I never again had someone teach me programming. Claudia had already taught me everything I needed to know, that code can always improve, that there's more than one way to skin a cat.

That the dinosaur was real and that some day soon my computer would be faster and nicer than the dinosaur was then, and that programming was cool, and that if I could find a way to draw a polynomial graph horizontally on a printer without ever having the whole graph in memory (it didn't fit), those future computers would do awesome things, and that I was one of the many who would help bring that to reality.

That talking about code was fun in itself, that you could make a modest living and be happy about it, that you could in any case make jigsaw puzzles in your spare time and keep on teaching or whatever.

And later the dinosaur's bones were scavenged into a line of racks holding routers, and its glass terminals are destroyed, and the gold in its teeth was stolen and the rare bus cables sold, and its circuits scrapped, but I saw the dinosaur alive, and Claudia taught me how to make it jump, and for that, I will always be grateful.

2010-03-24 05:03

Grok 1.0 Web Development

The people at Packt Publishing has been kind enough to send me a copy of Grok 1.0 Web Development by Carlos de la Guardia.

I have now read it (sorry it took so long!) and here's my review.

It's a well-written book. The exposition is clear and the author knows the subject and what he wants to say.

I was impressed by the straightforward approach of Grok when compared to what I dimly remember of ancient Zope experiences. The idea of a modern, agile, simple framework over Zope's admittedly powerful foundation has a lot of merit.

OTOH, I am not really convinced that I should drop Django for the small web projects I have scheduled, but if you are looking for a framework, and are not heavily invested in another, Grok is certainly worth checking out.

And, if you want to learn Grok, this book does the trick.

You can read a sample chapter or get more information about the book

2010-03-24 04:53

rst2pdf 0.14 released!

It's my pleasure to announce that I just uploaded rst2pdf 0.14 to the site at

Rst2pdf is a program and a library to convert restructured text directly into PDF using Reportlab.

It supports True Type and Type 1 font embedding, most raster and vector image formats, source code highlighting, arbitrary text frames in a page, cascading stylesheets, the full restructured text syntax and much, much more.

It also includes a sphinx extension so you can use it to generate PDFs from documents built with Sphinx.

In case of problems, please report them in the Issue tracker ( or the mailing list (

This release fixes several bugs and adds some minor features compared to 0.13.2. Here are some of the changes:

  • Fixed Issue 197: Table borders were confusing.
  • Fixed Issue 297: styles from default.json leaked onto other syntax highlighting stylesheets.
  • Fixed Issue 295: keyword replacement in headers/footers didn't work if ###Page### and others was inside a table.
  • New feature: oddeven directive to display alternative content on odd/even pages (good for headers/footers!)
  • Switched all stylesheets to more readable RSON format.
  • Fixed Issue 294: Images were deformed when only height was specified.
  • Fixed Issue 293: Accept left/center/right as alignments in stylesheets.
  • Fixed Issue 292: separate style for line numbers in codeblocks
  • Fixed Issue 291: support class directive for codeblocks
  • Fixed Issue 104: total number of pages in header/footer works in all cases now.
  • Fixed Issue 168: linenos and linenothreshold options in Sphinx now work correctly.
  • Fixed regression in 0.12 (interaction between rst2pdf and sphinx math)
  • Documented extensions in the manual
  • Better styling of bullets/items (Issue 289)
  • Fixed Issue 290: don't fail on broken images
  • Better font finding in windows (patch by techtonik, Issue 282).
  • Fixed Issue 166: Implemented Sphinx's hlist (horizontal lists)
  • Fixed Issue 284: Implemented production lists for sphinx
  • Fixed Issue 165: Definition lists not properly indented inside admonitions or tables.
  • SVG Images work inline when using the inkscape extension.
  • Fixed Issue 268: TOCs shifted to the left on RL 2.4
  • Fixed Issue 281: sphinx test automation was broken
  • Fixed Issue 280: wrong page templates used in sphinx


2010-03-19 14:34

If it's worth doing, it's worth doing right.

Yesterday in the PyAr mailing list a "silly" subject appeared: how would you translate spanish to rosarino?

For those reading in english: think of rosarino as a sort of pig latin, where the tonic vowel X is replaced with XgasX, thus "rosario" -> "rosagasario".

In english this would be impossible, but spanish is a pretty regular language, and a written word has enough information to know how to pronounce it, including the location of the tonic vowel, so this is possible to do.

Here is the thread.

It's looong but, final outcome, since I am a nerd, and a programmerm and programmers program, I wrote it.

What surprised me is that as soon as I started doing it, this throwaway program, completely useless...I did it cleanly.

  • I used doctrings.
  • I used doctests.
  • I was careful with unicode.
  • Comments are adequate
  • Factoring into functions is correct

A year ago I wouldn't have done that. I think I am finishing a stage in my (slow, stumbling) evolution as a programmer, and am coding better than before.

I had a tendency to, since python lets you write fast, write fast and dirty. Or slow and clean. Now I can code fast and clean, or at least cleaner.

BTW: this would be an excellent exercise for "junior" programmers!

  • It involves string manipulation which may (or may not) be handled with regexps.
  • Using tests is very quickly rewarding
  • Makes you "think unicode"
  • The algorithm itself is not complicated, but tricky.

BTW: here is the (maybe stupidly overthought) program,

# -*- coding: utf-8 -*-

Éste es el módulo gasó.

Éste módulo provee la función gasear. Por ejemplo:

>>> gasear(u'rosarino')

import unicodedata
import re

def gas(letra):
    '''dada una letra X devuelve XgasX
    excepto si X es una vocal acentuada, en cuyo caso devuelve
    la primera X sin acento

    >>> gas(u'a')

    >>> gas (u'\xf3')

    return u'%sgas%s'%(unicodedata.normalize('NFKD', letra).encode('ASCII', 'ignore'), letra)

def umuda(palabra):
    Si una palabra no tiene "!":
        Reemplaza las u mudas de la palabra por !

    Si la palabra tiene "!":
        Reemplaza las "!" por u

    >>> umuda (u'queso')

    >>> umuda (u'q!eso')

    >>> umuda (u'cuis')


    if '!' in palabra:
        return palabra.replace('!', 'u')
    if'([qg])u([ei])', palabra):
        return re.sub('([qg])u([ei])', u'\\1!\\2', palabra)
    return palabra

def es_diptongo(par):
    '''Dado un par de letras te dice si es un diptongo o no

    >>> es_diptongo(u'ui')

    >>> es_diptongo(u'pa')

    >>> es_diptongo(u'ae')

    >>> es_diptongo(u'ai')

    >>> es_diptongo(u'a')

    >>> es_diptongo(u'cuis')


    if len(par) != 2:
        return False

    if (par[0] in 'aeiou' and par[1] in 'iu') or \
    (par[1] in 'aeiou' and par[0] in 'iu'):
        return True
    return False

def elegir_tonica(par):
    '''Dado un par de vocales que forman diptongo, decidir cual de las
    dos es la tónica.

    >>> elegir_tonica(u'ai')

    >>> elegir_tonica(u'ui')
    if par[0] in 'aeo':
        return 0
    return 1

def gasear(palabra):
    Convierte una palabra de castellano a rosarigasino.

    >>> gasear(u'rosarino')

    >>> gasear(u'pas\xe1')

    Los diptongos son un problema a veces:

    >>> gasear(u'cuis')

    >>> gasear(u'caigo')

    Los adverbios son especiales para el castellano pero no
    para el rosarino!

    >>> gasear(u'especialmente')

    #from pudb import set_trace; set_trace()

    # Primero el caso obvio: acentos.
    # Lo resolvemos con una regexp

        return re.sub(u'([\xe1\xe9\xed\xf3\xfa])',lambda x: gas(,palabra,1)

    # Siguiente problema: u muda
    # Reemplazamos gui gue qui que por g!i g!e q!i q!e
    # y lo deshacemos antes de salir

    # Que hacemos? Vemos en qué termina

    if palabra[-1] in 'nsaeiou':
        # Palabra grave, acento en la penúltima vocal
        # Posición de la penúltima vocal:
        # Palabra aguda, acento en la última vocal
        # Posición de la última vocal:

    # Pero que pasa si esa vocal es parte de un diptongo?

    if es_diptongo(palabra[pos-1:pos+1]):
        pos += elegir_tonica(palabra[pos-1:pos+1])-1
    elif es_diptongo(palabra[pos:pos+2]):
        pos += elegir_tonica(palabra[pos:pos+2])

    return umuda(palabra[:pos]+gas(palabra[pos])+palabra[pos+1:])

if __name__ == "__main__":
    import doctest

2010-03-15 11:14

rst2pdf 0.13 released!

I've just uploaded the 0.13 version of rst2pdf, a tool to convert reStructured text to PDF using Reportlab to

rst2pdf supports the full reSt syntax, works as a sphinx extension, and has many extras like limited support for TeX-less math, SVG images, embedding fragments from PDF documents, True Type font embedding, and much more.

This is a major version, and has lots of improvements over 0.12.3, including but not limited to:

  • New TOC code (supports dots between title and page number)
  • New extension framework
  • New preprocessor extension
  • New vectorpdf extension
  • Support for nested stylesheets
  • New headerSeparator/footerSeparator stylesheet options
  • Foreground image support (useful for watermarks)
  • Support transparency (alpha channel) when specifying colors
  • Inkscape extension for much better SVG support
  • Ability to show total page count in header/footer
  • New RSON format for stylesheets (JSON superset)
  • Fixed Issue 267: Support :align: in figures
  • Fixed Issue 174 regression (Indented lines in line blocks)
  • Fixed Issue 276: Load stylesheets from strings
  • Fixed Issue 275: Extra space before lineblocks
  • Fixed Issue 262: Full support for Reportlab 2.4
  • Fixed Issue 264: Splitting error in some documents
  • Fixed Issue 261: Assert error with wordaxe
  • Fixed Issue 251: added support for rst2pdf extensions when using sphinx
  • Fixed Issue 256: ugly crash when using SVG images without SVG support
  • Fixed Issue 257: support aafigure when using sphinx/pdfbuilder
  • Initial support for graphviz extension in pdfbuilder
  • Fixed Issue 249: Images distorted when specifiying width and height
  • Fixed Issue 252: math directive conflicted with sphinx
  • Fixed Issue 224: Tables can be left/center/right aligned in the page.
  • Fixed Issue 243: Wrong spacing for second paragraphs in bullet lists.
  • Big refactoring of the code.
  • Support for Python 2.4
  • Fully reworked test suite, continuous integration site.
  • Optionally use SWFtools for PDF images
  • Fixed Issue 231 (Smarter TTF autoembed)
  • Fixed Issue 232 (HTML tags in title metadata)
  • Fixed Issue 247 (printing stylesheet)

2010-03-11 15:09

Finding a programmer that can program.

If you haven't read Jeff Atwood's Why Can't Programmers.. Program? go ahead, then come back.

Now, are you scared enough? Don't be, the problem there is with the hiring process.

Yes, there are lots of people who show up for programming positions and can't program. That's not unusual!

It's related to something I read by Joel Spolsky (amazingly, Jeff Atwood's partner in

Suppose you are a company that tries to hire in the top 1% of programmers, and have an open position.

You get 100 applicants. Of those, 99 can't program. 1 can. You hire him.

Then the company next door needs to do the same thing. They may get 100 applicant. 99 can't program ... and probably 80 of them are the same the previous company rejected before!

So no, hiring the best 1 out of 100 is not a way to get a programmer in the top 1% at all, that's just statistics intuition getting the worse of you.

You don't want to hire in the top 1% of applicants, you want to hire in the top 1% of programmers. Different universes.

These two things are the two sides of the same coin. 99% of applicants are useless, that's why they are applicants, because they can't get a job and they can't get a job because they are useless as programmers.

So, judging programmers by the standard of the applicants you get is like judging quality of a restaurant by licking its dumpster.

But now, having taken care of this, how do you find a programmer that can actually program?

Easy! Find one that has programs he can show you!

I would never hire a programmer that can't show me code. There must be something wrong with him, because programmers write programs.

That's just what we do. If we didn't what kind of programmers would we be?

Let's see some obvious objections to my argument:

  1. He wrote code for his previous employer and can't show it.

    So, he did. What else has he written? Some open source code? Maybe snippets in a blog? Answers in stackoverflow?

    Nothing? He has written nothing he was not paid to write? He is not who I want. He only programs for money, he lacks passion for programming, he doesn't enjoy it. He is probably not very good at it.

  2. He is just finishing college, he has not written much code yet!

    Why? What stopped him? He has been learning to program for years, what has he done with the knowledge he has been receiving? Saving it for his 25th brthday party? He has not practiced his craft? Not the programmer I need.

But having him show you code is not enough, of course. It also has to be good code, if you are serious about hiring excellent programmers.

So here's some bonus criteria:

  1. Check the languages he uses. If he codes COBOL for pleasure, he may or may not be what you want.
  2. Open source == bonus points: it means he is not ashamed of his code, plus it makes his credentials trivial to verify.
  3. If he leads a project with multiple contributors and does a good job he is half way to becoming a programmer/manager, so huge bonus points.
  4. Projects with long commit histories show responsability and a level head.
  5. Development mailing lists let you gauge his personality. Is he abrasive? Is he thin-skinned? Is he annoying?

Then there's the obvious stuff, references from previous employers, interviews, exercises, an such. But those are the least important filters, the most important thing is that he must be able to code. And showing you his code is the way to do it.

2010-03-03 19:28

Hacked on kuatia for a couple of hours...

As mentioned previously, I am hacking a bit on a proof-of-concept word processor. Right now, it's hosted on googlecode and called kuatia.

Now, it is far from being useful for anything, but... it can do nested itemized and bulleted lists.

Here's a screenie of the editor and the PDF output it produces via reStructured Text:


Personally I think that's not too bad.

2010-02-25 11:16

Marave 0.7 released

I just uploaded version 0.7 of Marave, my fullscreen text editor to

Marave is a "relaxing" text editor inspired by ommwriter, DarkRoom and many others. It combines a spartan fullscreen UI with a vanishing UI, which gets out of the way of your text.

It supports syntax highlighting, inine spellchecking, background music, audible keyboard feedback, themes, is extensible via plugins, and much more.

Here's a screenshot:


There are no major new features in 0.7, but there are important internal changes and some major bugs fixed:

  • Fixed bug that broke opening files if you had no spellchecker
  • Implemented basic RTL language support
  • Several other minor fixes
  • Refactored the editor component so it can be reused

2010-02-24 14:13

A teaser for an idea

I have been thinking on what I really really want in a word processor. And then what would it take to create such a thing.

A few minutes of playing have led me the way of this teaser (video here if you can't see it):

Could something come out of it? Who knows.

2010-02-23 14:23

Editor: a better QTextEdit

Writing an editor is reinventing the wheel. I know that. I tell myself Marave is a fine wheel, with distinct features, and I think that is true, but, if you are reinventing the wheel, there's no need to reinvent the axle and the spoke, too.

So, I refactored the stuff that I think a text editor must provide into a nice library, so the next time someone must invent a wheel, he can use Marave's neat spokes and axles:

So, introducing Editor, the most-obviously named class ever! It's a text editing widget for PyQt with extra features, which you can use as a drop-in replacement for a QTextEdit or QPlainTextEdit.

Right now, it lives inside Marave's SVN but it may even move out someday.

Here are its features:

  • Syntax highlighting

    And I don't mean "in theory", like QTextEdit and company do! Editor can highlight a bunch of languages, because it uses GNU source highlight via Lorenzo Bettini's Source Highlight Qt.

  • Spell checking

    If you have PyEnchant installed and the right dictionaries, it will do online spellchecking.

  • Search and Search+Replace widgets

    The Editor class can give you nice widgets for search or search and replace already hooked with the editor widget, so you can add them to your app's UI easily.

  • new/open/save/saveas methods:

    Don't implement opening/saving, etc yourself! That's always the same code!

Hopefully this will be helpful for someone else :-)

Contents © 2000-2019 Roberto Alsina