Tag Archives: python

Yet another silly Python vs Java comparison

I’ve been hacking the mspsim (a simulator) source to add support for a couple of stuffs in its profiler. At a certain point I had a hash table mapping functions to how many times they were called, and I had to sort them by that number of times. How to do that?

1
2
3
4
5
6
7
List<Entry<MapEntry, Integer>> list = new LinkedList<Entry<MapEntry, Integer>>(callers.entrySet());
Collections.sort(list, new Comparator<Entry<MapEntry, Integer>>() {
    @Override
    public int compare(Entry<MapEntry, Integer> o1, Entry<MapEntry, Integer> o2) {
      return o2.getValue().compareTo(o1.getValue());
    }
});

And if it were Python:

1
lst = sorted(((n, fn) for fn, n in callers.iteritems()), reverse=True)

Yep, Java can be a pain.

Of course it’s not that simple, though. I’ve tested another simulator in Python and its code is very nice and readable and warm and fuzzy…

…but it’s 30 times slower than the Java one.

Access violation errors with callbacks in ctypes

I’ve just spent a few hours trying to solve this bug, so I’m publishing this so maybe it will help someone with this issue…

Assume that you’re working with a DLL/.so library through ctypes in Python, and this library allows you to set a callback for some other function. In my case, I was working with unrar.dll. The code was something among these lines:

UNRARCALLBACK = ctypes.WINFUNCTYPE(ctypes.c_int, ctypes.c_uint, ctypes.c_long, ctypes.c_long, ctypes.c_long)
 
#in a class...
RARSetCallback(self.handle, UNRARCALLBACK(self.callback_fn), 0)
RARProcessFile(self.handle, RAR_TEST, None, None)

The first lines constructs the function prototype, the second sets the callback in a function of the DLL file, and the third calls a function in the DLL which will call the callback.

Can you spot the error?

The code worked fine in Python 2.5, but then I changed to 2.6 and it stopped working. I got a “WindowsError: exception: access violation reading…” (or writing) exception in the third call.

The reason, which is obvious in hindsight, is cleared explained in the docs:

Make sure you keep references to CFUNCTYPE objects as long as they are used from C code. ctypes doesn’t, and if you don’t, they may be garbage collected, crashing your program when a callback is made.

(Though it’s not explicit, it applies to WINFUNCTYPE objects too)

The WINFUNCTYPE object created in the second line no longer exists in the third line, so when the callback was called, it no longer pointed to a valid address. The solution is simple — just keep a reference to the object:

UNRARCALLBACK = ctypes.WINFUNCTYPE(ctypes.c_int, ctypes.c_uint, ctypes.c_long, ctypes.c_long, ctypes.c_long)
 
#inside a class...
self.callback_ref = UNRARCALLBACK(self.callback_fn)
RARSetCallback(self.rarFile.RAR._handle, self.callback_ref, 0)
RARProcessFile(self.rarFile.RAR._handle, RAR_TEST, None, None)

The only mystery left is why the old code worked on 2.5!

Porque eu reescrevi o Quivi do zero

Joel Spolsky, programador conhecido, disse em seu blog:

(…) Eles [da Netscape] fizeram isso tomando a pior decisão estratégica que uma compania de software pode fazer:

Eles decidiram reescrever o código do zero.

Em concordo, a princípio. Muitos projetos anunciam que foram “reescritos do zero” como se isso fosse algo maravilhoso, e na maioria das vezes, é só um sinal que a nova versão provavelmente tem mais bugs que a anterior.

Mas peraí, eu acabei de reescrever o Quivi (um visualizador de imagens e leitor de HQ’s / mangás) do zero! Por quê, então?

Bom, pensei que seria necessário me justificar. Essas são as razões:

  • É um projeto pequeno. Reescrevê-lo com certeza não é tão difícil quanto reescrever um navegador!
  • Eu não aguentava mais C++ (a linguagem de programação que eu utilizava). Claro, isso não é exatamente culpa do C++. Ele tem seus usos — a ferramente certa para o trabalho certo, e tudo o mais. Mas para escrever um programa de desktop? É canhão para matar formiga. Se você consegue (e gosta!) de fazer isso, eu admiro você. Mas eu não tinha mais motivação para trabalhar no Quivi.
  • Eu adoro Python (a linguagem de programação que eu uso agora), e claro,
    não sou o único. Programar é divertido em Python, tanto que eu tive a motivação de reescrever tudo, para começo de conversa! E claro, agora vai ser muito mais fácil para eu continuar trabalhando no Quivi.
  • Eu podia mudar de bibilioteca de interface. O SmartWin é uma boa bibilioteca, e use templates de formas interessantes; enquanto eu programava o Quivi eu acabei participando do desenvolvimento do SmartWin também. Mas ele tem os seus bugs, e justamente porque ele usa templates extensivamente, compilar um programa que o utilize é lento demais. Eu mudei para o wxPython, que é uma biblioteca de interface muito madura — e multi plataforma ainda por cima.

Claro, existem algumas desvantagens com a mudança. O pacote inteiro é muito maior devido às dependências (o instalador foi de 900K para 5MB!). E o programa é um pouco mais lento, principalmente na inicialização, e usa mais memória (9MB para 30MB com nenhum imagem aberta). Mas eu acredito que foi um bom compromisso.

Reescrever do zero deve ser estudado com cuidado, e neste caso, acredito que foi uma boa idéia. O Quivi é um hobby, e acho que o ponto principal é me divertir escrevendo ele, e atender às necessidades dos usuários. Espero que eu consiga fazer os dois com esta nova versão (que será lançada em breve).

Why I rewrote Quivi from scratch

Joel Spolsky, popular software engineering, said in this blog:

(…) They [Netscape] did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

I agree, mostly. Many projects market that they’ve been “rewritten from scratch” as if it was something marvelous, and most of time, it’s just a sign that the new version probably has more bugs than the previous. But, wait, I just rewrote Quivi (a image viewer and comic / manga reader) from scratch! Well, why?

Well, I thought I really had to justify this. So here are the reasons:

  • It is a small project. Rewriting it certainly isn’t as hard as rewriting a browser!
  • I couldn’t stand C++ anymore (the programming language I used before). Of course, this isn’t C++ fault per se. It has its uses — the right tool for the right job, and so on. But to write an desktop application? It’s overkill. If you manage to pull it of, hey, kudos to you. But I had no motivation to work on it anymore.
  • I love Python (the programming language I use now), and of course, I’m not the only one. Programming is fun in Python, so much that had the motivation to rewrite Quivi from scratch in the first place! And of course, it will be much more easier for me to keep working on Quivi.
  • I could change GUI libraries. SmartWin is a nice library, and uses templates in very interesting ways; when programming Quivi I ended up involved with its development too. But it has its bugs, and because it uses templates extensively, it’s awful slow to compile an application that uses it. I’ve changed to wxPython, which is a very mature GUI library – and cross platform to boot.

Of course, there are some downsides with the change. The whole software package is much bigger due to the dependencies (the installer jumped from 900K to 5MB!). And the program is a little bit slower, mainly when starting up, and uses more memory (9MB to 30MB with no images loaded). But I think it was a good enough trade-off.

Rewriting from scratch must be considered carefully, and in this case, I think it was a good idea. Quivi is a hobby project, and I guess the main point of it is to have fun writing it, and to make users happy. I hope I can do both with this new version (which will be released soon).

Python, Phyton… Pytohn?

Essa é nova:

As primeiras versões para Java e Pytohn já estão disponíveis para download a partir do serviço Google Code.

Não dá para entender a inabilidade geral das pessoas de escreverem “Python” direito.

Pegadinha com closures (ilustrado em Python)

(Embora ilustrado em Python, creio que conhecer Python não seja totalmente necessário para entender o post :) )

Você conhece o conceito de closures (“fecho”, mas acho que ninguém usa o termo em português…)? Basicamente, é quando você pode definir uma função em tempo de execução e esta função faz referência a variáveis de um escopo externo a ela. Por exemplo:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer
 
printer = make_number_printer(5)
printer()

A função make_number_printer recebe um número e retorna uma função que, quando chamada, imprime esse mesmo número. Não é a função mais útil do universo, mas ilustra bem o conceito de closure. No caso, a função number_printer é uma closure, pois referencia a variável n que está num escopo externo (o da função make_number_printer).

Porém minha intenção aqui não é tanto explicar o que são closures, mas sim ilustrar uma característica que pode acabar confundindo (já perdi um bom tempo caçando um bug causado por isso). O que esse código imprime?

printer_lst = []
for i in xrange(10):
    def number_printer():
        print i
    printer_lst.append(number_printer)
 
for printer in printer_lst:
    printer()

Ele executa um loop de 0 a 9, em cada iteração criando uma função number_printer e colocando-a numa lista, e em seguida percorre essa lista chamando todas as funções. Era de se esperar que ele imprimisse os números de 0 a 9, certo?

Errado! Ele imprime o número 9 dez vezes.

O problema é que na maioria das vezes, intuitivamente pensa-se que as closures funcionam “fixando” o valor das variáveis externas que elas referenciam para usá-las num momento posterior. Mas na verdades elas guardam uma referência àquela variável, e se ela mudar de valor, a closure usará o valor alterado. Como a nossa variável i vale 9 no final da criação das closures, esse é o valor que todas vão imprimir. Isso vale mesmo se a variável i deixar de existir após a criação das closures (por exemplo, se o primeiro for estivesse dentro de uma função).

Como resolver isso? Você pode mover a criação da closure para uma outra função, desta forma:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer
 
printer_lst = []
for i in xrange(10):
    printer_lst.append(make_number_printer(i))
 
for printer in printer_lst:
    printer()

Assim a closure irá referenciar a variável n, que possui instâncias diferentes para cada closure diferente criada. Outra alternativa é utilizar um “recurso” polêmico do Python, que é o fato de que os valores de parâmetros com valores padrão são avaliados quando a função é definida, e não quando ela é chamada:

printer_lst = []
for i in xrange(10):
    def number_printer(x=i):
        print x
    printer_lst.append(number_printer)
 
for printer in printer_lst:
    printer()

Ao executar def number_printer(x=i):, o valor de i é avaliado e salvo permanentemente na definição da função; assim, cada vez que a função é definida (a closure é criada) o valor atual de i é “congelado”.

Se alguém se estiver perguntando, “mas eu nunca vou acabar me deparando com isso”, este é um exemplo um pouco mais próximo da realidade (na verdade me bati com ele quando programava um jogo em Flash, que usa ActionScript). Fundamentalmente é o mesmo código acima e apresenta o mesmo problema:

class Button:
    #Esta é uma classe para simular um botão, suponha
    #que é parte de uma biblioteca de GUI e por alguma
    #razão você não pode herdar dela
 
    def __init__(self):
        self.listener = None
 
    def set_click_listener(self, fn):
        self.listener = fn
 
    def on_click(self):
        self.listener()
 
#Cria 10 botões...
buttons = [Button() for i in xrange(10)]
#E suponha que eles são adicionados na interface
 
#Seta os listeners para o evento de clique.
#O número de botões pode mudar no futuro
#e todos têm o mesmo código, a única diferença
#sendo o índice do botão. Então é melhor fazer isso
#dentro de um loop.
for i in xrange(10):
    def on_click():
        #Imagine que o código aqui seja mais útil
        print i
    buttons[i].set_click_listener(on_click)
 
#Simula um clique em cada botão
for j in xrange(10):
    buttons[j].on_click()

Closure gotcha (with Python)

Do you know what a closure is? Basically, it’s a function created at runtime that references variables defined in a outer scope. For example:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer
 
printer = make_number_printer(5)
printer()

The function make_number_printer receives a number and returns a function which, when called, prints that same number. It’s not the most useful function in the world, but it does show how closures work. In this case, the number_printer function is a closure, because it references the variable n which is in an outer scope (of the make_number_printer function).

My intention here, though, it’s not to explain what closures are but to show a property of them which may cause some confusion (and made me spent quite some time hunting for a bug caused by it). What does this code prints when run?

printer_lst = []
for i in xrange(10):
    def number_printer():
        print i
    printer_lst.append(number_printer)
 
for printer in printer_lst:
    printer()

It loops between 0 and 10 creating a number_printer function and appending it to a list. Then it loops through the functions of the list, calling them. You would expect it to print the numbers 0 to 9, right?

Wrong! It prints the number 9 ten times.

The problem is that most people (including me, before learning this) think that closures work by evaluating the variables in the outer scope and storing their values to use when necessary. But actually they keep an reference to those variables, and if their contents change, the closure will use the new value. Since our variable i stores the value 9 after the closures are created, that is the value they will print. This happens even if the variable i goes out of scope after the closures are created (e.g., if the first for were inside a function).

So how to solve this? You can move the creation of the closure to another function, like this:

def make_number_printer(n):
    def number_printer():
        print n
    return number_printer
 
printer_lst = []
for i in xrange(10):
    printer_lst.append(make_number_printer(i))
 
for printer in printer_lst:
    printer()

Here the closure will reference the variable n, which has different instances for each different closure created. Another alternative is to use a somewhat contrived Python “feature” which is the fact that default parameter values are evaluated when the function is defined and not when they are called:

printer_lst = []
for i in xrange(10):
    def number_printer(x=i):
        print x
    printer_lst.append(number_printer)
 
for printer in printer_lst:
    printer()

When def number_printer(x=i): is run, the variable i is evaluated and its value is saved in the function definition; so, each time the function is defined (i.e., the closure is created), the current value of i is “frozen”.

If somebody is thinking, “but I’ll never run into this situation”, here is a little more real example (which actually happened to me when I was coding a Flash game, which uses ActionScript). Basically it’s the same code above and has the same issue:

class Button:
    #This is a dummy Button class; suppose
    #it's part of a GUI library and for some reason
    #you can't subclass it
 
    def __init__(self):
        self.listener = None
 
    def set_click_listener(self, fn):
        self.listener = fn
 
    def on_click(self):
        self.listener()
 
#Create 10 buttons...
buttons = [Button() for i in xrange(10)]
#And suppose the buttons are added to the GUI after
 
#Set the listeners to the click event.
#The number of buttons may change in the future
#and all of them have the same code, the
#only difference is the button index. So it's better
#to do this within a loop. 
for i in xrange(10):
    def on_click():
        #Suppose there is something more useful here
        print i
    buttons[i].set_click_listener(on_click)
 
#Simulate a click in each button
for j in xrange(10):
    buttons[j].on_click()