Igor Sobreira

Testing infinite loops

2013-03-17T00:00:00-10:00

Yesterday I was working on a script that should run forever, or at least until the user stops it. The library behind it was already tested except for this little function:

def collect(directory):
    sequential = Sequential(directory)
    live = Live(directory)

    while 1:
        live.process()
        sequential.process()

this is the entry point of my library. I have an executable that just parses a directory name from command line and call this function. It's purpose it to collect all files from a directory, filter based on some rules, and publish the file names in a queue which will be consumed by another script. It runs forever because newly created files are detected and collected too.

Anyway, what it does doesn't really matter, the problem is: how to test this function since it's supposed to run forever?

I don't mind to have just unit tests for this function because I already have more integration-like tests for the classes it uses. The first solution I thought was something like this:

def collect(directory):
    sequential = Sequential(directory)
    live = Live(directory)

    while should_continue():  # new function to mock on tests: UGLY!
        live.process()
        sequential.process()

def should_continue():
    return True

this way I could mock should_continue() in my test and make it return False to abort the loop when I want. That works but it's ugly! I don't like to add dependency injections only for tests.

I asked on #python on irc and marienz gave a neat idea: raise an exception. I could mock live.process() and sequential.process() and raise an exception, this way I know they were called as I expected and also it will also abort the loop!

import pytest
import mock

# this is the library under test
import collectors

# replace original classed with mock objects
@mock.patch('collectors.Sequential')
@mock.patch('collectors.Live')
def test_collect_should_loop_forever_processing_both_collectors(
        collectors_Live, collectors_Sequential):

    # build mock instances. process() method will raise error
    # when called for the 2nd time. The code for `ErrorAfter`
    # is bellow
    seq = mock.Mock(['process'])
    seq.process.side_effect = ErrorAfter(2)
    live = mock.Mock(['process'])
    live.process.side_effect = ErrorAfter(2)

    # ensure mocked classes builds my mocked instances
    collectors_Sequential.return_value = seq
    collectors_Live.return_value = live

    # `ErrorAfter` will raise `CallableExhausted`
    with pytest.raises(CallableExhausted):
        collectors.collect('/tmp/files')
    
    # make sure our classed are instantiated with directory
    collectors_Sequential.assert_called_once_with('/tmp/files')
    collectors_Live.assert_called_once_with('/tmp/files')

This test uses py.test and mock. I hope the comments explains enough. The idea is simple: make process() raise an Exception to abort the loop. The ErrorAfter class is a small helper, it builds a callable object that will raise a specific exception after n calls. I created a custom exception here to make sure my test fails if any other exception is raised. See the code bellow.

class ErrorAfter(object):
    '''
    Callable that will raise `CallableExhausted`
    exception after `limit` calls

    '''
    def __init__(self, limit):
        self.limit = limit
        self.calls = 0

    def __call__(self):
        self.calls += 1
        if self.calls > self.limit:
            raise CallableExhausted

class CallableExhausted(Exception):
    pass

Conclusion

Try to avoid as much as possible to create dependency injections specifically for your tests. In dynamic languages like Python it's very easy to replace a specific component with a mock object without adding extra complexity to your code just to allow unit testing.

This was the first time I had to test a infinite loop, it's possible and easy!

Start simple

2013-01-03T00:00:00-10:00

Last week I wrote a post about unnecessary classes, and that kept me thinking about how common people write classes or more complex designs upfront just because it would be easier to evolve and extend later.

One suggestion I gave was to use a dictionary instead of a class which had no methods but the constructor. This class was just holding state, data, so a dictionary is enough. Let's start simple...

I'll stick with this example because it's real code, even if it's purpose is not 100% clear:

def create_button_link(matchobject, line):
    button_link = matchobject.groupdict()
    button_link.update({
        'name': matchobject.group(0),
        'size': int(button_link['size']),
        'colors': button_link['colors'][1:].split("."),
        'line': line
    })
    return button_link

this function returns a dictionary with many properties of a button, ok. But now I need to increase its size, I could write a function like:

def increase_button_link_size(button_link, pixels):
    button_link['size'] += pixels
    return button_link

At some point you may want to change the design and make a ButtonLink class, maybe because you need a much more complex model and OO could help. Anyway, here is how the class could be implemented:

class ButtonLink(object):
    def __init__(self, matchobject, line):
      self.__dict__ = matchobject.groupdict()
      self.name = matchobject.group(0)
      self.size = int(self.size)
      self.colors = self.colors[1:].split(".")
      self.line = line
      
    def increase(self, pixels):
        self.size += pixels

the problem now is that button_links are being used as dictionaries all over the place, like button_link['size']. And even worse, this could be a public API and you may not have access to the clients using it. In this case we could simulate the dict api implementing __getitem__:

import warnings

class ButtonLink(object):
    # ... same as above
    
    def __getitem__(self, item):
        warnings.warn("Dict-like access is deprecated, please use `.{0}`"
                      .format(item), DeprecationWarning)
        return getattr(self, item)

Now you can use button_link.size and button_link['size']. And I also added a deprecation warning to notify the users that they should use the object API from now on. And you should also modify the functions above to create and manipulate the object instead of the dictionary, also raising warnings if you want.

You may want to implement other dictionary methods, like keys, items, has_key, __contains__, etc.

Why not make a dict subclass?

The main reason I wouldn't subclass dict in this case is philosophical: ButtonLink should behave like a dict (temporarily), but it is not a dictionary. A good example of a dict subclass is OrderedDict, it is a dictionary with customized behavior.

Another aspect to keep in mind is when we write a subclass is that we inherit all the methods from the superclass, all the API, and it's now part of my class API. In my case I don't want to implement the __setitem__ method, because the clients should not be using it, all the time you need to modify the button_link dict there is a specialized function to do so, and these functions I can easily rewrite to use the object API.

"What about isinstance()?!". Yeah, you're going to loose it, since button_link is not a dict anymore isinstance(button_link, dict) is False. But I believe you should not be using it, type checking with isinstance() and even worse, type(), is not very common on languages like python. "If it walks like a duck and quacks like a duck, then it is a duck"! I know that sometimes isinstance() is handy, but I don't think it's appropriate here because of the philosophical argument I gave above.

Conclusion

Start simple, it's always easier to evolve to a more complex design than the other way around.

Using Python magic methods your objects can easily look like a native data structure, so start using simple data structures and write your own if you need later. Another language feature that helps this incremental design evolution is properties, a simple attribute can evolve to a complex getter/setter transparently.

Don't forget the Zen of Python:

Simple is better than complex. Complex is better than complicated.

Unnecessary classes

2012-12-31T00:00:00-10:00

Today I opened a python module that made me feel sad. It has two classes: one of them has 4 methods, all of them static, and no attributes; the other has only one method: __init__, and 5 attributes.

Why people still write classes like these?

Use functions

...instead of classes with just static methods. If you have this class just to group the functions in a common namespace then create a new module (.py file), this is how python organize namespaces, and it's good, use it!

Here is the first class I saw today

class Buttonate(object):

    @staticmethod
    def find_files(quiet=False):
        # ...
    
    @staticmethod
    def find_links(files):
        # ...
    
    @staticmethod
    def buttonate(buttons, overwrite=False, quiet=False):
        # ...

    @staticmethod
    def link_parser(file):
        # ...

and here is how I would rewrite it:

def buttonate_find_files(quiet=False):
    # ...

def buttonate_find_links(files):
    # ...

def buttonate_buttonate(buttons, overwrite=False, quiet=False):
    # ...

def buttonate_link_parser(file):
    # ...

I usually just start creating the functions I need, and if I get to this point where I have multiple functions doing related work I just create a module and move them there:

# new file: buttonate.py

def find_files(quiet=False):
    # ...

def find_links(files):
    # ...

def buttonate(buttons, overwrite=False, quiet=False):
    # ...

def link_parser(file):
    # ...

Use builtin data structures

...instead of attributes-only-classes. Here is the other class I saw today:

class ButtonLink(object):
    def __init__(self, matchobject, l):
      self.__dict__ = matchobject.groupdict()
      self.name = matchobject.group(0)
      self.size = int(self.size)
      self.colors = self.colors[1:].split(".")
      self.line = l

This is a class being used similar to a struct in C. We could use a dictionary here, and a factory function doing the work __init__ is doing in this example:

def create_button_link(matchobject, line):
    button_link = matchobject.groupdict()
    button_link.update({
        'name': matchobject.group(0),
        'size': int(button_link['size']),
        'colors': button_link['colors'][1:].split("."),
        'line': line
    })
    return button_link

Dictionaries are fast, well designed and are always being improved by smart people.

Another interesting builtin data structure is namedtuple. And it has a clever implementation, you should check it out :)

One rule I follow when using dictionaries like the example above is to always modify them with specialized functions. You'll end up with well defined structures and modules that know how to build and manage these structures inside your application.

What I'm suggesting here is actually the opposite of OO, instead of writing a class with state and methods, keep the state on dictionaries (or tuples, lists, sets) and write functions to manipulate the state. I've been using this approach much more that classes lately.

References

Stop writing classes is a great talk by Jack Diederich at PyCon 2012, showing examples where classes are overused.

Python coverage threshold

2012-11-05T00:00:00-10:00

Ned Batchelder committed a new feature to coverage.py 2 days ago, it's a way to verify coverage threshold. Basically a way to fail your tests if the coverage is not enough. For now you need to install from the repository to get the new feature

$ pip install hg+https://bitbucket.org/ned/coveragepy#egg=coverage

This is how to use from the command line:

$ coverage run run_my_tests.py 
... running all tests
$ coverage report --fail-under=100
... display the report
$ echo $?
2

If your coverage is not 100% your exit status will be 2. This will make your CI fail if your coverage is not enough :). You can also verify coverage using the python API, in this case you need to verify the return value from report() function, here is an example:

cov = coverage.coverage(..)
cov.start()
ret = run_all_my_tests()
cov.stop()
if ret == 0:
    covered = cov.report()
    assert covered > 100, "Not enough coverage"
...

I've created a decorator to make this easier:

def ensure_coverage(percentage, **cov_options):
    def decorator(function):
        @wraps(function)
        def wrapper(*args, **kw):
            cov = coverage.coverage(branch=True, **cov_options)
            cov.start()
            ret = function(*args, **kw)
            cov.stop()
            if ret == 0:
                covered = cov.report()
                assert covered >= percentage, \
                    "Not enough coverage: {0:.2f}%. You need at least {1}%".format(covered, percentage)
            return ret
        return wrapper
    return decorator

This is an usage example for this django app I'm working on:

@ensure_coverage(99, source=['filecabinet'], omit=['filecabinet/tests/*'])
def runtests():
    test_runner = get_runner(settings)()
    return test_runner.run_tests(['filecabinet'])

if __name__ == '__main__':
    sys.exit(runtests())

Here are the related commits, if you're interested:

https://bitbucket.org/ned/coveragepy/changeset/7ea709fc4c1190cf0ffe0aba1a49e6fffe683d2f https://bitbucket.org/ned/coveragepy/changeset/90014f4defd336f05851bdfc01c2b5af60a933c9 https://bitbucket.org/ned/coveragepy/changeset/ba7267fe525001dba99ed1c2c9d11f0724ad9950

And the discussion on the issue:

https://bitbucket.org/ned/coveragepy/issue/139/easy-check-for-a-certain-coverage-in-tests

Improving performance of Django test suite

2012-09-19T00:00:00-10:00

I'm working on a small django application these days which offers templates to override django-filebrowser's templates to remove the Grappelli dependency.

It's a small app, consisting 99% of templates. There are only 19 tests which take 35 seconds to execute! All of them performs at least one request using django test client, no selenium, no real HTTP requests, and still 35 seconds!

After a run with cProfile I've noticed many calls to hash functions, specifically django.utils.crypto.pbkdf2() and it's helper _fast_hmac. Then I came up with this very complex patch to my settings:

+    PASSWORD_HASHERS = (
+        'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',   
+    ),

Now the tests execute on 6 seconds!

You probably want a safer hash function for your user passwords in production, but there is no problem to use a simpler one for tests. This extensible way to deal with password hashers was introduced in Django 1.4, you can read more about it on the docs.

Vagrant plugin to take screenshots

2012-03-13T00:00:00-10:00

I've been using Vagrant a lot at work. These days we were facing some problems when our VMs were booting and a friend, jbochi, came up with an idea to take a screenshot from a running VM.

He found this command on VBoxManage:

$ VBoxManage controlvm [vm-uuid] screenshotpng [output-filename]

And it helped a lot! That's when we had the idea to wrap this command in a script to keep using. Initially I've created a small python script, but then reading about vagrant plugins (hltbra's suggestion) I've decided to create one.

The vagrant-screenshot plugin is very simple. You just need to install the gem and use:

$ gem install vagrant-screenshot

Here is an usage example:

$ vagrant screenshot -o
[vagrant] Taking screenshot for default
[vagrant] Screenshot saved on screenshot-default.png

By default it takes screenshots for all active VMs. The -o (--open) option opens the images when done (only works on OS X for now)

See the help for more details

$ vagrant screenshot --help

PS.: The problem I've mentioned we were facing ended up in a pull request to vagrant, but unfortunately it wasn't accepted :o)

Book review - Being Geek

2011-12-28T00:00:00-10:00

I've finished reading this book, Being Geek, by Michael Lopp, an experienced engineering manager from Silicon Valley. And recommend it...

It's a book about geeks professionalism, career. I liked the way the author exposes his ideas, he's clear and pragmatic. Right in the second chapter there are these three questions I think it's worth pointing out:

Are you actively defining the technical direction for your product?
Do you understand what you need to do in order to grow?
Are you hitting your dates? Are you meeting your commitments? Are you doing what you say you’re going to do?

That's it! That's what you need to ask yourself every day. Those answers will make you realize if this job is being useful for you to archive your professional goal in your life.

Later in the book he talks about task management, to-do lists and so on. And a very interesting one he calls "The Trickle List". This is not a simple to-do list for that day. It's a list of tasks you do every day with a bigger goal in mind, in the future. If you want to be a better engineer, every day you may want to learn something, improve on something, read something. I suddenly realized I was missing this list...

Well, I liked the book. I was not very excited reading the first chapters. But as I continued reading it just got better and better. The author writes comfortably about our career, being an engineer or a manager. The book is full of good advices based on experience. Hiring process, remote working, giving presentations, etc.

Command line interface to FMS Admin

2011-12-25T00:00:00-10:00

I've been working with Flash Media Server for the last 8 months now, and one tool that really annoys me is the Administration Console. I miss a command line interface to accomplish tasks like see all live streams, reload an app, etc.

That's why I've started the fms-admin-api. It's a command line client to Flash Media Server Administration API. Since it's written in ruby, it's possible to use the ruby client class directly. Use rubygems to install:

$ gem install fms-admin-api

The way it works is really simple. Here is an example: there is a reloadApp() method available that accepts the arguments host, auser, apswd and appInst. The command line interface just replaces from camelCase syntax to underscore:

$ fmsapi reload_app --host=fms.example.com --auser=fms --apswd=secret --app_inst=live

There are improvements to be made and help is welcome.

Change object after saving all inlines in Django Admin

2011-02-12T00:00:00-10:00

UPDATE Aug, 2011: This patch added a new hook to ModelAdmin called save_related(). You don't need the hack described bellow anymore :).

Admin is an awesome Django builtin app to create nice CRUDs for your models, and offers a lot of customizations hooks. You can personalize the templates, perform custom filters, modify newly created objects and if that's not enough, you can always create your own view to do something it doesn't by default.

The admin docs are great, I'm not going to explain how it works. The intention here is to show a way to modify an object, after it's saved, and other objects related to it using inlines are saved too.

Once you've configured your admin interface with inlines, you end up with something similar to:

from django.contrib import admin
from fooapp.models import Foo, Related

class RelatedInline(admin.TabularInline):
    model = Related

class FooAdmin(admin.ModelAdmin):
    inlines = [RelatedInline]

admin.site.register(Foo, FooAdmin)

this mean whens you're adding a Foo, since Related has a foreign key to it, django will display a few forms to add Relateds in the same page.

Imagine you need to do something with the new foo instance that needs to now how many related objects it has. Admin already has methods you can override to do something after Foo is saved, like ModelAdmin.save_model(). See how it works:

class FooAdmin(admin.ModelAdmin):
    inlines = [RelatedInline]

    def save_model(self, request, obj, form, change):
        obj.save()
        # do something with obj.related_set.all()
        # OPS! it's empty!

admin.site.register(Foo, FooAdmin)

the problem here is that save_model() is called before the inlines are saved.

Let's find out how it works. Open django source code, specifically in django.contrib.admin.options.py go to add_view(), it's the view called when you are creating an object. As you can see, when the request method is "POST" it goes through all validation, for the main form and all related formsets (your inlines). And if all of then are valid it calls save_model(), then save_formset() for each formset. The interesting piece is shown below:

class ModelAdmin(BaseModelAdmin):

    # ...

    def add_view(self, request, form_url='', extra_context=None):
        
        # ... all validation here ...
        
        if all_valid(formsets) and form_validated:
            self.save_model(request, new_object, form, change=False)
            form.save_m2m()
            for formset in formsets:
                self.save_formset(request, form, formset, change=False)

            self.log_addition(request, new_object)
            return self.response_add(request, new_object)

Notice here that the last method it calls is response_add(), and it passes the created object, that's all we need! If you see the change_view() method (witch it the view called when you're editing an object) it calls a similar method: response_change().

Now we can solve our problem doing something like this:

class FooAdmin(admin.ModelAdmin):
    inlines = [RelatedInline]

    def response_add(self, request, new_object):
        obj = self.after_saving_model_and_related_inlines(new_object)
        return super(FooAdmin, self).response_add(request, obj)

    def response_change(self, request, obj):
        obj = self.after_saving_model_and_related_inlines(obj)
        return super(FooAdmin, self).response_change(request, obj)

    def after_saving_model_and_related_inlines(self, obj):
        print obj.related_set.all()
        # now we have what we need here... :)
        return obj

There are two things to keep in mind when using these methods:

They are not documented. So probably it's not part of the API admin expects you to override. Thankfully django publishes excellent release notes including backwards incompatible changes. And I hope you have good test coverage to know if it will break when you update django :)
Their intention is to handle the response of the view, as it docstring says: "Determines the HttpResponse for the add_view stage". So if you do something there not related to it, it works, wont make much sense if you look at the overall architecture.

Maybe django will add a more specific hook to solve this issue later, but I hope it helps you for now.

Adding methods dynamically in Python

2011-02-06T00:00:00-10:00

Given the dynamic nature of Python you can do many things in runtime, like add methods dynamically to an object or class. This is particularly useful when writing unit tests.

Here is the simplest way, adding a method to and object:

class Person(object):
    pass

def play():
    print "i'm playing!"

p = Person()
p.play = play
p.play()

note that play is just a function, it doesn't receive self. There is no way to p knows that it's a method. If you need self, you must create a method and then bind to the object:

from types import MethodType

class Person(object):
    def __init__(self, name):
        self.name = name

def play(self):
    print "%s is playing!" % self.name

p = Person("igor")
p.play = MethodType(play, p)
p.play()

In these examples, only the p instance will have play method, other instances of Person won't. To accomplish this we need to add the method to the class:

class Person(object):
    def __init__(self, name):
        self.name = name

def play(self):
    print "%s is playing!" % self.name

Person.play = play

p1 = Person("igor")
p1.play()

p2 = Person("joh")
p2.play()

note that we don't need to create a method with types.MethodType here, because all functions in the body of a class will become methods and receive self, unless you explicit say it's a classmethod or staticmethod.

Adding methods to builtin types

Python doesn't allow to add methods to built-in types, actually to any type defined in C. The unique way around this is to subclass the type, here is an example:

class UpperList(list):
    pass

def to_upper(self):
    for index, item in enumerate(self):
        self[index] = item.upper()

UpperList.to_upper = to_upper

l = UpperList(['i','g','o','r'])
l.to_upper()
print l

Here is a nice comparison on dynamically adding methods in Python and Ruby.

Mocks, Stubs, Fakes and Spies

2010-12-15T00:00:00-10:00

Reading the Continous Delivery book I found a good definition of mocks, fakes, stubs and spies:

"Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production. A good example of this is the in-memory database.
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don’t expect and are checked during verification to ensure they got all the calls they were expecting."

This terminology was taken from xUnit Test Patterns book.

I've already seen cases where people write lot's of unit tests, abusing from mock objects, but without good integration and acceptance tests you can't really guarantee that each scenario is really working as expected.

"It’s very easy to misuse mocks to write tests that are both pointless and fragile, using them simply to assert the specific details of the workings of some code, rather than an assertion of interactions with collaborators."

A couple links if you want to read more about it:

Extending the User model in Django

2010-12-11T00:00:00-10:00

Django brings a built-in user authentication system, it includes an User model which has the most common attributes. But in most applications you may need to store additional attributes to users. Django has a way to do this too.

Extending using foreign key

Basically you create your UserProfile model with a OneToOneField to User:

class UserProfile(models.Model):
    user = models.OneToOneField('auth.User')
    bio = models.TextField()
    # ...

and define in on settings.py

AUTH_PROFILE_MODULE = 'accounts.UserProfile'     # app name (dot) model name

From now on your User objects will have a get_profile() method.

I personally can't see a reason to use this setting (and I hate "getters" methods), you just need to do this:

class UserProfile(models.Model):
    user = models.OneToOneField('auth.User', related_name='profile')
    bio = models.TextField()
    # ...

See the related_name='profile' parameter, now you don't need the get_profile() method anymore, just use user_instance.profile.

But there is a small problem here, if the user instance don't have a profile related to it you will receive an ObjectDoesNotExist exception. This happens with get_profile() too. And it's not good to handle the exception every time you access the profile. The simplest way to solve this is connect to django.db.models.signals.post_save on the User model and create your UserProfile instance related to it

from django.db.models import signals
from accounts.models import UserProfile

def create_user_profile(sender, instance, created, **kwargs):
    if created:
        UserProfile.objects.create(user=instance)

signals.post_save.connect(create_user_profile, sender=User)

Why subclassing User is a bad idea

There are a few reasons I prefer to create user profiles as another model instead of just subclassing the default User. If you think for a while, an user has a lot to do in your site, and there are at a few default steps:

first she needs to register, confirm by email, and so on
login and logout, change and reset password
admins may need to manage groups and permissions, to restrict user actions, offer features to specific groups
manage profile, with personal information

Django doesn't handle the first topic, there is a great app to handle registration.

The second and third topics can be done with django.contrib.auth app, this is exactly it's purpose.

And then you have the forth topic, which is profiles. As you can see, it can be done as a separate app. A user has a profile. So makes sense to have a profile attribute in the User object.

If you split features in apps like this it's easier to reuse too, that's the idea of django apps after all! The django-registration is an example. And as you can imagine, there are apps to manage profiles too.

Editing User profile in admin

If you're using admin you may want to edit the UserProfile fields in the same page as the User fields, and it's possible using admin inlines. Here is how you admin configuration will look like:

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin as DjangoUserAdmin
from django.contrib.auth.models import User

from accounts.models import UserProfile

class UserProfileInline(admin.TabularInline):
    model = UserProfile

class UserAdmin(DjangoUserAdmin):
    inlines = (UserProfileInline,)

admin.site.unregister(User)
admin.site.register(User, UserAdmin)

Conclusion

As you can see, it quite easy to manage user profiles in django. Although there is a way to hook you profile model in settings.py, you can do it with a simple foreign key. And as usual, there are a few reusable apps around to handle the generic stuff.

Slides - Desenvolvimento web com Python e Django

2010-11-08T00:00:00-10:00

Segue os slides da minha palestra Desenvolvimento web com Python e Django.

Apresentei essa palestra no Jatic, na faculdade Facisa em Campina Grande, PB. E também no CITOS, na faculdade Univem, em Marília, SP.

A maior parte da apresentação fala sobre Django, mas também mostra como funciona o WSGI, as maneiras mais comuns de fazer deployment de aplicações em python hoje em dia, configuração de ambiente usando virtualenv, testes...

Desenvolvimento web com python e django

Veja outras aprensentações minhas no Slideshare.

Campos numéricos localizados no Django

2010-09-25T00:00:00-10:00

A criação de campos numéricos ficou muito mais fácil no Django na versão 1.2. Imagine o seguinte model:

class Debito(models.Model):
    descricao = models.CharField(max_length=256)
    valor = models.DecimalField(max_digits=10, decimal_places=2)
    
    def unicode(self):
        return self.descricao

E seu registro no admin

admin.site.register(Debito)

Ao tentar cadastrar um valor numérico, por exemplo: 1.450,60, receberíamos um erro já que esse formato não era entendido como numérico. Agora, basta informar que esse campo precisa ser localizado. Como isso é feito no formulário, e não no model, vamos sobrescrever o formulário padrão do admin

class DebitoForm(forms.ModelForm)
    valor = forms.DecimalField(max_digits=10, decimal_places=2, localize=True)

    class Meta:
        model = Debito

class DebitoAdmin(admin.ModelAdmin):
    form = DebitoForm

admin.site.register(Debito, DebitoAdmin)

Note o parâmetro localize no campo DecimalField do formulário.

Estamos quase lá, só precisamos nos certificar de que as seguintes configurações estão no settings.py

USE_L10N = True         # essa é padrão
USE_THOUSAND_SEPARATOR = True

Mas ainda tem um detalhe, se você tentar acessar debito.valor vai receber uma instância da classe decimal.Decimal do python, e ainda terá que formatar manualmente. Felizmente o django já possui uma função pra fazer isso. Para facilitar, você pode adicionar um método no seu model:

from django.utils.formats import number_format

class Debito(models.Model):
    descricao = models.CharField(max_length=256)
    valor = models.DecimalField(max_digits=10, decimal_places=2)

    def __unicode__(self):
        return self.descricao

    @property
    def valor_formatado(self):
        return u"R$ %s" % number_format(self.valor, 2)

Agora sim, basta acessar debito.valor_formatado.

Confira a documentação para mais detalhes.

Até a próxima!

Difference between _, and xx__ in Python

2010-09-16T00:00:00-10:00

When learning Python many people don't really understand why so much underlines in the beginning of the methods, sometimes even in the end like __this__! I've already had to explain it so many times, it's time to document it.

One underline in the beginning

Python doesn't have real private methods, so one underline in the beginning of a method or attribute means you shouldn't access this method, because it's not part of the API. It's very common when using properties:

class BaseForm(StrAndUnicode):
    ...
    
    def _get_errors(self):
        "Returns an ErrorDict for the data provided for the form"
        if self._errors is None:
            self.full_clean()
        return self._errors
    
    errors = property(_get_errors)

This snippet was taken from django source code (django/forms/forms.py). This means errors is a property, and it's part of the API, but the method this property calls, _get_errors, is "private", so you shouldn't access it.

Two underlines in the beginning

This one causes a lot of confusion. It should not be used to mark a method as private, the goal here is to avoid your method to be overridden by a subclass. Let's see an example:

class A(object):
    def __method(self):
        print "I'm a method in A"
    
    def method(self):
        self.__method()
     
a = A()
a.method()

The output here is

$ python example.py 
I'm a method in A

Fine, as we expected. Now let's subclass A and customize __method

class B(A):
    def __method(self):
        print "I'm a method in B"

b = B()
b.method()

and now the output is...

$ python example.py
I'm a method in A

as you can see, A.method() didn't call B.__method() as we could expect. Actually this is the correct behavior for __. So when you create a method starting with __ you're saying that you don't want anybody to override it, it will be accessible just from inside the own class.

How python does it? Simple, it just renames the method. Take a look:

a = A()
a._A__method()  # never use this!! please!

$ python example.py
I'm a method in A

If you try to access a.__method() it won't work either, as I said, __method is just accessible inside the class itself.

Two underlines in the beginning and in the end

When you see a method like __this__, the rule is simple: don't call it. Why? Because it means it's a method python calls, not you. Take a look:

>>> name = "igor"
>>> name.__len__()
4
>>> len(name)
4

>>> number = 10
>>> number.__add__(20)
30
>>> number + 20
30

There is always an operator or native function that calls these magic methods. The idea here is to give you the ability to override operators in your own classes. Sometimes it's just a hook python calls in specific situations. __init__(), for example, is called when the object is created so you can initialize it. __new__() is called to build the instance, and so on...

Here's an example:

class CrazyNumber(object):
    
    def __init__(self, n):
        self.n = n
    
    def __add__(self, other):
        return self.n - other
    
    def __sub__(self, other):
        return self.n + other
    
    def __str__(self):
        return str(self.n)


num = CrazyNumber(10)
print num           # 10
print num + 5       # 5
print num - 20      # 30

Another example:

class Room(object):

    def __init__(self):
        self.people = []

    def add(self, person):
        self.people.append(person)

    def __len__(self):
        return len(self.people)

room = Room()
room.add("Igor")
print len(room)     # 1

The documentation covers all these special methods.

Conclusion

Use _one_underline to mark you methods as not part of the API. Use __two_underlines__ when you're creating objects to look like native python objects or you wan't to customize behavior in specific situations. And don't use __just_to_underlines, unless you really know what you're doing!

Customize settings.py locally in Django

2010-09-12T00:00:00-10:00

The django configuration file is pure python code, this gives us a lot of flexibility to setup settings when the application starts. Actually you could even modify settings in runtime, but promise me you won't do this, ever!

Imagine you have an open-source django project, you have your code in github or something like that, but you probably don't want to publish your DATABASES configuration. Or maybe you can add all your server configuration under version control, it's private, great, but your local configuration is probably different too, you will need to set DEBUG = True at least.

There are a few ways to extend the settings.py file...

Use the --settings option

The manage.py command has a --settings option that you can use to specify a different settings file, so you could have a local_settings.py file similar to:

from settings import 

DEBUG = True
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.sqlite3',
        'NAME': 'db.sqlite',
        'USER': '',
        'PASSWORD': '',
        'HOST': '',
        'PORT': '',
    }
}

And locally you use:

$ python manage.py runserver --settings=local_settings

This is the simplest way to extend the settings.py file and is probably enough for most situations, but let's take a look in other options.

Importing from settings.py

This method is the opposite from above. In the end of your settings.py you add:

try:
    from local_settings import 
expect ImportError:
    pass

Now you local_settings.py file won't need to import anything from settings.py, just set your configuration variables. And you don't need to pass --settings anymore.

Adding code dynamically to settings.py

This is similar to the method above but gives you more flexibility. Imagine you need a local_settings.py file similiar to this:

DEBUG = True
INTERNAL_IPS = ('127.0.0.1',)
MIDDLWARE_CLASSES = MIDDLWARE_CLASSES + ('debug_toolbar.middleware.DebugToolbarMiddleware',)
INSTALLED_APPS = INSTALLED_APPS + ('debug_toolbar',)

How could you use MIDDLWARE_CLASSES or INSTALLED_APPS from settings.py if you didn't import those? Here is the answer:

import os

PROJECT_ROOT = os.path.dirname(file)
try:
    execfile(os.path.join(PROJECT_ROOT, 'local_settings.py'), globals(), locals())
except IOError:
    pass

The trick here is the execfile function, it reads the content of the file and appends it to the file you calling from. In the end, it's like the contents of you local_settings.py file are inside settings.py.

Host specific settings

Now you already have a way to customize your settings locally, just create a local_settings.py file, don't add it under version control, and add one of these code snippets in the end of your settings.py.

But what if you need specific settings per host? You have this project that runs on multiple servers, and you want specific settings for each one. You could create a settings_.py file, and import dynamically:

import socket
import os

PROJECT_ROOT = os.path.dirname(file)
settings = 'settings_%s.py' % socket.gethostname()

try:
    execfile( os.path.join(PROJECT_ROOT, settings), globals(), locals())
except IOError:
    pass

To view your hostname just execute:

$ hostname
globo-mac

so, in my case I have a file called settings_globo-mac.py

Conclusion

That's it! How I said in the beginning, settings.py is just python, this gives us a lot of power to customize our settings dynamically. If you have another idea let us know.

See you!

Replacing render_to_response with direct_to_template in Django

2010-09-11T00:00:00-10:00

Update: September 3, 2012

A render() was introduced on Django 1.3 to use RequestContext by default

You certainly have already used render_to_response to render your templates, it's a very convenient shortcut:

from django.shortcuts import render_to_response

def myview(request):
    ...
    return render_to_response('template.html', {'foo': ['one', 'two']})

At least until you need to use context processors, then you start writing code like this

from django.shortcuts import render_to_response
from django.template import RequestContext

def myview(request):
    ...
    return render_to_response('template.html', 
            {'foo': ['one', 'two']},
            context_instance=RequestContext(request))

this context_instance argument is the boilerplate code you will always need to make context processors work. I think it's too much typing, and I'm lazy, so I prefer to use the direct_to_template generic view:

from django.views.generic.simple import direct_to_template

def myview(request):
    ...
    return direct_to_template(request, 'template.html', 
            {'foo': ['one', 'two']})

You don't need the context_instance argument anymore, and you save one import.

But! There is one simple detail when passing extra context to this view, if a value in your dict is a callable, it will call and pass the result to template. It can be useful, but is something to keep in mind, if you're trying to pass a callable to template.

Read the source code to understand how it works.

Django readonly fields in Admin

2010-02-20T00:00:00-10:00

Finally Django has implemented readonly fields in Admin interface. It's a new feature in 1.2 which is in alpha version at this moment, but will be released soon.

The feature is really simple and is already documented so I won't explain how it works. But there is one implementation detail not documented that gives much more power to this feature. If you check the admin sources, you'll find a method called get_readonly_fields() in django/contrib/admin/options.py, by default it just returns self.readonly_fields, which is the normal usage, but since you receive the request object as a parameter you can enable or not some fields depending on the logged in user.

Here is an example where a slug field can just be edited by superusers:

class FooModelAdmin(admin.ModelAdmin):
    ...
    def get_readonly_fields(self, request, obj=None):
        if request.user.is_superuser:
            return ()
        return ('slug',)

There are lot's of interesting new features in Django 1.2, I'm looking forward for it!

Python 3.1.1. error on startup

2009-12-29T00:00:00-10:00

After installing Python 3.1.1 for Mac OS on my Leopard I got an error trying to start python3 from Terminal:

$ python3
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: 
Abort trap

There is a "fixed" issue in the bug tracker but the problem persists in my installation. A quick workaround is to set LC_CTYPE properly. Check how it is now with the locale command (mine was UTF-8)

$ export LC_CTYPE=en_US.UTF-8

Add this to your ~/.profile.

Ajax File Upload with jQuery

2009-09-21T00:00:00-10:00

I've been looking for an Ajax upload plugin for jQuery yesterday. And actually I found some interesting solutions, but any of then did what I wanted.

I needed a multi file upload. I had a form with many file inputs and I wanted it to just works, using Ajax. The options available that supports multi file upload (without flash), are limited to just one file input, and you can choose more that one file from it. It's nice, but not what I needed.

Then I found this one: Ajax File Upload. It only supports one file input too, but I've hacked it to support more that one, and still be able to send more data (the other fields values of my form) to the server.

Internally it creates a new form, and put it inside an iframe, and so on. Well, it just works, and it was easy to modify for my needs.

Usage

$.ajaxFileUpload({
    url : '/url/to/post/',
    
    // here you pass a jQuery selector with all your file inputs.
    // this is the main change I've made, in the original version you had to pass an
    // ID of you file input
    fileElements : $('input[type=file]'),
    
    // also supports json, xml and script
    dataType : 'html',
    
    success : function(response) { 
        alert('hey, it worked')
    },
    error : function(xhr, status, error) { 
        alert("you've got a problem here")
    },
    
    // here you pass an object with all extra data you want to send.
    // it didn't existed in the original version
    extraData : {foo: 'bar'}
});

Download

You can download it here. And the original can be found here, you will find more usage examples there too.

If you're insterested, here is the diff with my changes.

I hope it's useful for you too.

1º Encontro do GrupyPB

2009-08-21T00:00:00-10:00

Ontem teve o 1º Encontro do GrupyPB, o grupo de usuários Python aqui da Paraíba. O grupo foi criado a algum tempo, e tentamos organizar um encontro mais de uma vez, mas sempre tinha um impecilho, trabalho, universidade, etc. Dessa vez conseguimos!

O encontro aconteceu na FATEC, que deu todo o apoio e estrutura. Foi interessante ver que Python tá sendo realmente usado aqui na Paraíba em diversas áreas: web, mobile, desktop, e até conversando com Arduínos. Tivemos uma tarde de palestras, e no final tinhamos planejado um Coding Dojo, que acabou virando mais um aulão de Python, já que muitos ainda não conheciam a linguagem. O que eu achei bem interessante, prova que nós próximos encontros e Dojos teremos mais pythonistas.

A primeira palestra foi minha, sobre Python na Web, a idéia era somente mostrar como Python pode ser usado na web. Falei um pouco sobre o padrão WSGI, uma visão sobre alguns frameworks e a possibilidade de montar o seu, usando módulos existentes.

Depois Flávio Ribeiro falou sobre Python na plataforma Symbian. As vantagens e desvantagens, e uma visão geral de como python tá sendo adotado no mundo de dispositivos móveis. E com direito a uma apresentação do marmota, um de seus projetos pessoais. Um carrinho equipado com um Arduíno controlado pelo celular com PyS60 tomou conta do auditório.

Luiz Thiago falou sobre a filosofia que está por trás do Python. O Zen Of Python, a PEP 008, que propõe um estilo para os códigos ficarem o mais legível possível. Achei interessante mostrar ao pessoal novo como a comunidade e os core developers prezam pela beleza de código e facilidade de leitura.

Por fim, Raniere Fernandes, ou Raninho, falou sobre Python e Qt, confesso que foi a mais esperada por mim, principalmente depois do lançamento do PySide essa semana. Qt é realmente show! Fiquei muito interessado em aprender.

As palestras estão acessíveis na página do encontro no site: grupypb.net. Ou direto no slideshare, na tag, grupypb.

Espero que mais encontros venham periodicamente. Se você é daqui da Paraíba (ou não), entre no grupo do google e cadastre-se no site grupypb.net. Até o próximo encontro.

Skype derrubando conexão

2009-05-21T00:00:00-10:00

A versão nova do Skype dava problemas com minha conexão, no OS X, simplesmente derrubava a conexão. Pra contornar o problema baixei uma versão mais antiga do skype e fiquei usando. Mas faltavam muitas novidades, como o vídeo.

Agora eu resolvi googlar mais um pouco e tentar resolver o problema. Descobri que não é com o Skype, mas com meu modem, um SpeadStream 4200, especificamente com o Universal Plug and Play (UPnP). Eu desabilitei o UPnP do meu modem e agora o Skype funciona.

Depois dou uma estudada melhor como o UPnP funciona, e procuro uma solução menos "gambiarrosa" pra isso. Mas fica a dica pra quem tiver com o mesmo problema.

Suprimir DeprecationWarning

2009-04-28T00:00:00-10:00

Algumas funcionalidades estão depreciadas no Python 2.6, e como alguns módulos externos ainda não estão atualizados, DeprecationWarnings são lançados. O MySQLdb, por exemplo, lança o:

DeprecationWarning: the sets module is deprecated

No meu caso, sempre que eu rodo o manage.py runserver no Django vejo esse warning, o que é bem chato. Para filtrá-lo, basta adicionar essas linhas no seu manage.py

import warnings
warnings.simplefilter('ignore', DeprecationWarning)

Isso já foi resolvido na versão beta do MySQLdb, porém o Django ainda não suporta essa versão, devido a muita coisa ter sido reescrita, mas suportará na versão 1.1, segundo um dos core developers

Só tenha cuidado pra não filtrar todos os warnings sempre, e deixar algum aviso importante passar despercebido.

Estruturas de dados do Django

2009-04-15T00:00:00-10:00

O Django tem um módulo com algumas estruturas de dados bem úteis, que ele usa internamente. Fica em django.utils.datastructures.

Uma delas é a SortedDict, como o nome mesmo já diz, é um dicionário que mantém as chaves ordenadas. Já vi muita gente perguntando como ordenar os itens de um dicionário, taí um jeito.

Ele faz isso herdando de dict e mantendo uma lista interna (keyOrder) com a ordem real das chaves. Não é algo complicado de se fazer, mas já ter lá pronta pra usar é uma mão na roda. O dicionários de campos (self.fields) dos formulários do Django são instâncias de SortedDict, por exemplo.

Outra bem interessante é a MultiValueDict, um dicionário onde cada chave pode ter mais de um valor.

Bem, fica a dica! Um bom começo, pra quem usa Django, pra começar a dar uma fuçada nos fontes.

Python weakref

2009-04-14T00:00:00-10:00

Existe um módulo bem interessante na biblioteca padrão do Python que eu não conhecia até pouco tempo atrás, o weakref. Ele serve pra manter uma "referência fraca" para um objeto. Mas o que seria isso? Uma weak reference não é suficiente para manter o objeto na memória, então se só existir esse tipo de referência para o objeto, o coletor de lixo vai destruí-lo.

Isso é interessante pra evitar um alto consumo de memória com objetos muito grandes que não deveriam mais estar vivos. Um problema que pode acontecer usando o padrão de projeto Observer (~~mal implementado~~), por exemplo .

Um exemplo

>>> class Foo(object):
...   def say_hello(self): print 'say hello'
... 
>>> a = Foo()
>>> a.say_hello()
say hello
>>> r = weakref.ref(a)

r é uma referência fraca para o objeto a

>>> r() is a
True
>>> r().say_hello()
say hello
>>> del a
>>> from gc import collect
>>> collect()    # forçando a coleta de lixo
0
>>> print r()
None

Já existem classes úteis que usam weak references: WeakKeyDictionary e WeakValueDictionary. Vale a pena dar uma olhada na documentação:

http://docs.python.org/library/weakref.html

Customizando o prompt interativo do Python

2009-03-12T00:00:00-10:00

Acredito que todo desenvolvedor que usa Python já deve ter o ipython instalado. É uma shell interativa que traz várias vantagens sob a que vem na instalação padrão do Python. Uma delas é autocompleta usando tabs.

Mas tem como configurar a shell padrão pra autocomplete com tabs, histórico (com seta pra cima), ou o que mais você quiser.

Antes do interpretador iniciar, ele lê a variável de ambiente PYTHONSTARTUP, e executa o conteúdo do arquivo pra onde ela aponta. Lá, você pode configurar algumas preferências pra o prompt.

Primeiro baixe esse arquivo: pbp.scripts. É um conjunto de códigos usados no livro Expert Python Programming, de onde eu tirei essa dica.

Dentro desse pacote, tem o script pythonstartup.py. Renomei ele para .pythonstartup e copie para sua pasta home. No meu caso, no OS X, ficou: /Users/igorsobreira/.pythonstartup

Depois é só setar a variável de ambiente apontando pra ele

$ export PYTHONSTARTUP=/Users/igorsobreira/.pythonstartup

Para esse export ser executado sempre que a shell do seu usuário iniciar, no OS X pode adicionar no arquivo ~/.profile. No linux, ~/.bash_profile.

Agora é só testar:

>>> import sys
>>> sys.<tab><tab>
...

MySQL-python no Mac OS

2008-12-29T00:00:00-10:00

MySQL-python é o módulo que o Python usa para se conectar a bancos MySQL. Tive um probleminha pra instalar ele aqui no Mac OS, mas é um bug conhecido, e já tem a solução no oráculo. Mas vou documentar aqui também.

Primeiro, baixar o pacote. E descompactar:

$ tar xvzf MySQL-python-1.2.2.tar.gz
$ cd MySQL-python-1.2.2

Se você não tiver o mysql_config no PATH, é preciso editar o setup-posix.py, onde tiver

mysql_config.path = "mysql_config"

mudar para o caminho completo

mysql_config.path = "/usr/local/mysql/bin/mysql_config"

Caso ainda retorne o erro:

In file included from /usr/local/mysql/include/mysql.h:47,
                 from _mysql.c:40:
/usr/include/sys/types.h:92: error: duplicate 'unsigned'
/usr/include/sys/types.h:92: error: two or more data types in declaration specifiers
error: command '/usr/bin/gcc-4.0' failed with exit status 1

Basta comentar, no arquivo _mysql.c, a linha

#define uint unsigned int

Agora é só instalar

$ sudo python setup.py install

Properties no Python 2.6

2008-12-28T00:00:00-10:00

Uma das features que eu mais gosto em Python são as properties. Elas são possíveis graças aos descriptors, mas isso é assunto pra outro post. E na versão 2.6, as properties ganharam 3 atributos: getter, setter e deleter. Veja mais aqui

Primeiro, vou mostrar como elas sempre funcionaram. Ai vai um exemplo "dummy", não levem em conta a funcionalidade em si (sou péssimo em exemplos):

class Conta(object):
    def __init__(self, saldo = 0.0):
        self.saldo = saldo
    
    def depositar(self, valor):
        if valor > 0:
            self.saldo += valor
            return True
        return False

Certo, uma classe Conta, onde eu posso depositar um valor, que incrementa meu 'saldo'. Mas como ver o saldo? Os "Javeiros" de plantão perguntariam logo: "Onde está o getter do saldo?!". E eu respondo: "Não tem :-)". Simplesmente porque não precisa. Se você quiser ver o saldo, acesse o atributo direto:

>>> c = Conta(100.00)
>>> print c.saldo
100.00
>>> c.depositar(20.00)
>>> print c.saldo
120.00

Mas isso não fere o encapsulamento? Um dos princípios básico da OO!?! É aí que entra as properties. Em Python, atributos são acessados diretamente, só se você precisar fazer algo quando acessá-lo, ai você cria um getter, e transforma o atributo numa property. Vejamos como ficaria a classe Conta:

from datetime import datetime

class Conta(object):
    def __init__(self, saldo = 0.0):
        self._saldo = saldo
        self._ultimo_acesso = None
    
    def depositar(self, valor):
        if valor > 0:
            self._saldo += valor
            return True
        return False
    
    def _get_saldo(self):
        self._ultimo_acesso = datetime.now()
        return self._saldo
    
    saldo = property(_get_saldo)

Agora, ao acessar a 'property' saldo, estaremos chamando o método _get_saldo(). O cliente da classe continua com a mesma API. Veja que eu usei um underline (_) na frente dos atributos, isso em Python é uma convenção, pra informar que o atributo é "privado", já que não existem atributos realmente privados.

>>> c = Conta(100.00)
>>> print c.saldo
100.00
>>> print c._ultimo_acesso
2008-12-28 14:30:05.598644

Ou seja, getters e setters? Somente quando precisar. Confesso que depois de conhecer essa feature, dá dor na vista ler códigos em Java, PHP, etc...com vários getX, getY, getZ somente com uma linha retornando o atributo equivalente.

Uma property é um descriptor que conecta funções ao acesso a um determinado atributo. Tem a seguinte assinatura:

property(fget=None, fset=None, fdel=None, doc=None)

Vamos criar um setter para a classe acima:

def _set_saldo(self, novo_saldo):
    if novo_saldo > 0:
        self._saldo = novo_saldo

# a property agora seria
saldo = property(_get_saldo, _set_saldo)

Aqui vai o código na íntegra, com alguns doctests: conta.py.

Sim, mas o que mudou no Python 2.6? Veja como eu poderia criar o getter e setter:

@property
def saldo(self):
    self._ultimo_acesso = datetime.now()
    return self._saldo

@saldo.setter
def saldo(self, novo_saldo):
    if novo_saldo > 0:
        self._saldo = novo_saldo

Aqui está o código moficado: conta2.py.

Referências:

mod_wsgi no OSX

2008-12-16T00:00:00-10:00

Finalmente consegui botar o mod_wsgi pra funcionar no OSX, usando o Python 2.6. Tive problemas compilando na mão com o Apache que já vem instalado no sistema, então resolvi instalar tudo com macports.

Primeiro instalei o Python 2.5.2, depois o Python 2.6.1, deixando como default o 2.6.1. Meu medo era o comando python_select abaixo sobrescrever o python default do sistema (o /usr/bin/python), e dar problemas internos, mas o /usr/bin/python continua lá, com o 2.5.1 "mechido" pela Apple :-).

$ sudo port install python25
$ sudo port install python26
$ sudo python_select python26

Pronto, agora instalar o Apache, também pelo macports

$ sudo port install apache2
$ sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

Se você estava usando o Apache que já vem no sistema (como eu), não esqueça de desativar em System Preferences -> Sharing.

Agora pra instalar o mod_wsgi, eu alterei algumas coisas no Portfile, já que a versão que tava lá era antiga, e pedia o Python 2.4. Seguei abaixo meu Portfile:

/opt/local/var/macports/sources/rsync.macports.org/release/ports/www/mod_wsgi/Porfile

É isso, um script simples pra testar se tudo tá funcionando:

def application(environ, start_response):
    start_response('200 OK',  [('Content-type','text/plain')])
    return ['Ola mundo!\n']

Salve em /opt/local/apache2/htdocs/test.wsgi. Edite seu /opt/local/apache2/conf/httpd.conf e adicione a linha:

WSGIScriptAlias /wsgi/test /opt/local/apache2/htdocs/test.wsgi

Basta reiniciar o Apache

$ sudo /opt/local/apache2/bin/apachectl restart

E acessar a url /localhost/wsgi/test

Tive problemas tentando compilar o mod_wsgi (com macports) com o python 2.6, e a versão padrão do sistema (com python_select) sendo o 2.5, dava uns erros com a função start_response. Mas agora tudo (aparentemente) funciona bem.

Django 1.0!

2008-08-31T00:00:00-10:00

A versão 1.0 do Django acaba de sair, veja a notícia do lançamento aqui.

Se tiver migrando de uma versão mais antiga, ou até mesmo do trunk um pouco desatualizado, veja o que quebrou compatibilidade, e aproveite! :-)

Auto-complete no Django

2008-06-03T00:00:00-10:00

Existe um script no diretório extras do Django que oferece auto-complete nos scripts django-admin.py e no manage.py, é o django_bash_completion. Para usar basta adicionar a seguinte linha no seu arquivo ~/.bashrc

. /home/igor/django-trunk/extras/django_bash_completion

substituindo pelo seu diretório do django. Começará a funcionar quando você se logar novamente.

Eu utilizo a versão do trunk, não sei se esse escript vem no tarball da versão 0.96, provavelmente sim.

Palestra sobre Django no ECD

2008-05-29T00:00:00-10:00

Hoje eu dei uma palestra sobre Django, no II Encontro Comunicação Digital, uma rápida introdução, seguida de um exemplo prático, onde eu fiz lá uma aplicação simples pra controle de gastos.

Os slides e o código fonte do exemplo estão aqui. Espero que seja útil.

Novo usuário Gentoo!

2008-04-06T00:00:00-10:00

Sempre fui usuário Ubuntu, porém meu "sempre" não é lá grande coisa já que eu uso Linux a pouco mais de 2 anos. Testei um pouco o Fedora e OpenSuse também, mas o Ubuntu foi o que gostei mais, o velho "apt-get" é muito bom! Até conhecer o emerge....

Pra mim uma boa distro era aquela fácil de usar, que já vem tudo pronto. Tem coisa mais fácil que instalar um Ubuntu? Em meia hora você tem um sistema completo rodando. O único problema que cheguei a ter foi com wireless, mas as versões mais novas já detectavam direto.

Na ultima versão, o Ubuntu Gutsy Gibbon, 7.10, eu tive alguns probleminhas chatos que começaram a me incomodar. Como por exemplo a interface gráfica travava com frequencia(provavelmente por causa de minha placa de vídeo ATI). Somente o famoso "ctrl + alt + backspace" pra resolver. E começou a ficar um pouco lento também, vá lá que meu processador não é lá grande coisa (Intel Celerom 1.73GHz), mas acho que dava pra ficar melhor.

Ai resolvi começar a usar o Gentoo. Sempre tive vontade de usar, mas a longa e trabalhosa instalação sempre me assustou um pouco. Não só pelo fato de ser "difícil", mas ia tomar muito tempo e eu não tinha como ficar 2 dias sem meu computador. Um dia desses comecei a dar uma lida no Handbook e tomei coragem. Passei um final de semana configurando e compilando o kernel do Gentoo, e na segunda tava "pronto". Gentoo 2007.0, Kernel 2.6.24-gentoo-r3 e KDE 3.5. Mas ainda faltava atualizar pra o Python 2.5, wireless, placa de som e instalar muitos aplicativos.

Depois que comecei a usar, bateu o arrependimento: "Por que não instalei antes?!". Nunca vi meu computador tão rápido. O portage é muito bom! Na instalação você escolhe cada módulo que quer habilitar no Kernel, isso deixa o sistema enxuto e muito rápido, só com o essencial.

Realmente dá um trabalho enorme pra instalar, pra quem tá acostumado com Ubuntu, Fedora, etc. Mas vale muito a pena, você começa a ter mais controle do sistema, entender melhor como as coisas funcionam (afinal você faz praticamente "tudo").

Ainda falta configurar algumas coisas, faz somente uma semana que tou usando, provavelmente ainda vou recompilar o kernel algumas vezes. Mas pra quem quer aprender mais sobre Linux e usar um sistema altamente customizado, acho que é a melhor solução.

Construtores e Destrutores em Python e PHP 5

2008-03-14T00:00:00-10:00

Estava aqui brincando com Orientação a Objetos no PHP 5, e não pude evitar uma comparação com Python. Percebi que os contrutores e destrutores funcionam praticamente da mesma maneira, provavelmente na maioria das linguagens deve ser assim.

Em Python o construtor é o método __init__ da sua classe. Bem, Mark Pilgrim, autor do Dive into Python tem uma opinião diferente:

"__init__ is called immediately after an instance of the class is created. It would be tempting but incorrect to call this the constructor of the class. It's tempting, because it looks like a constructor (by convention, __init__ is the first method defined for the class), acts like one (it's the first piece of code executed in a newly created instance of the class), and even sounds like one (“init” certainly suggests a constructor-ish nature). Incorrect, because the object has already been constructed by the time __init__ is called, and you already have a valid reference to the new instance of the class. But __init__ is the closest thing you're going to get to a constructor in Python, and it fills much the same role. "

Eu concordo com essa explicação, mas aqui vou chamar __init__ de construtor mesmo.

No Python funciona assim: você tem uma classe A, e uma classe B que herda de A. Se a class A tiver o método __init__, mas a classe B não tiver, ao se instanciar a classe B, o interpretador vai procurar o construtor, não achando na classe atual, vai subindo para as classes base, chamando o primeiro que encontrar, no caso o da classe A. Confuso? Vejamos em código...

class A(object):
    def __init__(self):
        print 'estou na classe A'
    
class B(A):
    pass

Instanciando a classe B pra ver o que acontece:

>>> b = B()
estou na classe A

Ou seja, como a classe B não tinha um construtor (__init__), o interpretador foi subindo para as classes base até achar um, e não precisou ir muito longe, a classe A já tinha.

Mas se definirmos o __init__ na classe B, ele vai ser executado e pára por ai:

class A(object):
    def __init__(self):
        print 'estou na classe A'
    
class B(A):
    def __init__(self):
        print 'estou na classe B'

E o resultado será

>>> b = B()
estou na classe B

Mas e se quisermos que o __init__ da classe A fosse executado também? Nesse caso precisariamos chamá-lo explicitamente. Isso pode ser feito com a função super()

class A(object):
    def __init__(self):
        print 'estou na classe A'
    
class B(A):
    def __init__(self):
        print 'estou na classe B'
        super(B, self).__init__()

E o resultado será como esperado

>>> b = B()
estou na classe B
estou na classe A

Atenção! Esse comportamento de construtores do Python acontece tanto para classes old style quanto para classes new style(que herdam de object). Porém o super() só funciona com classes new style. Uma sintaxe alternativa seria: A.__init__(self)

A mesma coisa acontece com PHP 5 e seu construtor, o __construct, vejamos o mesmo exemplo

class A {
    public function __construct() {
        echo "Estou na classe A";
    }
}
class B extends A { }

$b = new B;

A saída do código abaixo será:

Estou na classe A

Mas e se definirmos o __construct da classe B, como chamar o da class A também? Vejamos o exemplo:

class A {
    public function __construct() {
        echo "Estou na classe A";
    }
}
class B extends A {
    public function __construct() {
        parent::__construct();
        echo "Estou na classe B";
    }
}

$b = new B;

A saída será:

Estou na classe A
Estou na classe B

Em relação aos destrutores a idéia é a mesma. No Python seria o método __del__, e no PHP 5 o __destruct. Um exemplo com Python:

class A(object):
    def __init__(self):
        print 'nascendo...'
    
    def __del__(self):
        print 'morrendo........'

Testando...

>>> a = A()
nascendo...
>>> del a
morrendo........
>>> a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' is not defined

O mesmo exemplo em PHP:

class A {
    public function __construct() {
        echo "Nascendo..";
    }
    public function __destruct() {
        echo "Morrendo.....";
    }
}

$a = new A;
unset($a);

E a saida será:

Nascendo..
Morrendo.....

Linux com cara de Windows

2008-03-13T00:00:00-10:00

Pra quem tem vontade de migrar de windows pra Linux, mas acha o Linux muito complicado, o Famelix é uma distribuição que facilita essa migração.

Projeto de pesquisa iniciado em março de 2003, o Famelix GNU/Linux começou de maneira despretenciosa, com o objetivo de atender a sua comunidade local.

Contudo, após mais de 3 anos e matéria traduzidas para mais de 40 línguas, o FAMELIX despertou o interesse mundial

PIL - IOError - decoder jpeg not available

2008-03-12T00:00:00-10:00

Eu estava com um problema com a PIL, o módulo pra manipulação de imagens do python, sempre que tentava manipular uma imagem .jpg recebia esse erro:

IOError: decoder jpeg not available

O problema é que tava faltando a libjpeg, mas mesmo depois que eu instalei, nao tinha dado certo porque não tinha removido a instalação atual da PIL, então vou botar os passos aqui que finalmente fez a coisa funcionar no Debian e Ubuntu.

Primeiro remover a PIL que ta dando erro (como root):

# rm -rf /usr/lib/python2.5/site-packages/PIL
# rm -rf /usr/lib/python2.5/site-packages/PIL.pth 
# rm -rf Imaging-1.1.6  # onde quer que tenha instalado

Agora instalar a libjpeg

# aptitude install libjpeg libjpeg-dev
# aptitude install  libfreetype6 libfreetype6-dev

Baixar novamente a PIL, e instalar

# wget http://effbot.org/media/downloads/Imaging-1.1.6.tar.gz
# tar xvzf Imaging-1.1.6.tar.gz
# cd Imaging-1.1.6
# python setup.py build_ext -i

Rodar os testes pra verificar se realmente não tem problemas

# python selftest.py

e instalar

# python setup.py install

É isso ai.

Programando em Java no Gedit

2008-03-11T00:00:00-10:00

Pois é, aqui estou eu programando em Java...esse período estou pagando uma cadeira de de POO, e ~~infelizmente~~ é com Java. Na verdade meu curso é quase todo em Java.

Mas eu uso o Gedit pra programar, e agora? Instalar o Eclipse ou ou alguma outra IDE? Por enquanto não. Existe um plugin no Gedit chamado External Tools, que já vem nele, talvez precise habilitar em Edit -> Preferences -> Plugins. Com ele você pode executar códigos externos. Como por exemplo compilar e executar um arquivo em java.

Pra compilar vá em Tools -> External Tools, e adicione um novo, no comando adicione:

echo "Compiling: " $GEDIT_CURRENT_DOCUMENT_PATH
javac $GEDIT_CURRENT_DOCUMENT_PATH

Pode botar uma tecla de atalho se quiser.

E pra executar o código, eu fiz um script em python, e adicionei no diretório: ~/.gedit/java_run.py. Segue o código Atualizado em 13/03:

#!/usr/bin/python
import sys
from os import system, chdir

if len(sys.argv) != 3:
    print "Can't run program"
    sys.exit(0)

chdir(sys.argv[1])
command = 'java %s' % sys.argv[2].replace('.java','')
system(command)

E adicione um novo "External Tool" com o seguinte código:

#Runs a compiled Java source file.
echo "Running: " $GEDIT_CURRENT_DOCUMENT_PATH
echo '--------------------'
python ~/.gedit/java_run.py $GEDIT_CURRENT_DOCUMENT_DIR  $GEDIT_CURRENT_DOCUMENT_NAME

Pronto. Agora o Gedit é quase uma IDE Java. :)

II Encontro do Comunicação Digital

2008-03-10T00:00:00-10:00

Nos dias 28 a 30 de Maio, vai acontecer o II Encontro do Comunicação Digital, no CEFET-PB, João Pessoa-PB. Esse é um evento anual, e esse ano será a segunda edição.

O Núcleo Comunicação Digital começou com um grupo de alunos voluntários que usavam e defendiam o software livre, principalmente o Linux, e decidiram se juntar para divulgá-lo. Além dessa idéia, de difusão do Linux, linguagens de programação opensource, etc, também veio a idéia de dividir conhecimento, criar a apoiar projetos de pesquisa, organizar eventos, ministrar palestras, cursos, grupos de estudo, etc.

O primeiro evento, realizado em Abril de 2007 foi um sucesso, com várias palestras e workshops, e foi muito elogiado pelos congressistar, ministrantes e profissionais que participaram. Veja mais detalhes e fotos aqui.

Esse ano o evento traz algumas novidades, como a apresentação de Postêrs, Mesas Redondas, e um processo de inscrição e submissão de palestras totalmente online e automatizado. Além das palestras e workshops, cujo período de submissão ja está aberto. Aliás, não poderia deixar de falar, o site do evento foi feito em Django! :o)

Esperamos que esse ano o número de participantes seja ainda maior. Participe, inscreva-se ou submeta um trabalho.

Mensagens para os usuários no Django

2008-02-13T00:00:00-10:00

Ultimamente tenho usado muito a aplicação de autenticação do Django. Mas não estava muito satisfeito com o sistema de mensagens para os usuários que é oferecido. Na verdade a intenção é ser realmente bem simples, vejamos um exemplo:

def alterar_foto(request):
    # executa o código da view aqui....
    request.user.message_set.create(message=u'Foto alterada')
    return render_to_response('usuarios/dados.html',
                              context_instance=RequestContext(request))

Foi adicionado uma mensagem para o usuário, assim podemos criar uma fila das últimas ações executadas pelo mesmo. Só que o método para acessar essas mensagens é o get_and_delete_messages():

mensagens = user.get_and_delete_messages()

e no template, assumido que esteja usando RequestContext, ficaria assim:

<ul>
{% for message in messages %}
    <li>{{ message }}</li>
{% endfor %}
</ul>

pois o RequestContext define no template a variável messages, que são as mensagens do usuário logado. Mas como o próprio nome do método já diz, quando as mensagen são acessadas, elas são removidas. Eu não gostei muito disso, pelo fato de o usuário só poder ver as últimas ações uma única vez, além de que não tem um campo de data no model Message, pra mostrar o dia e hora daquela ação.

Daí decidi reinventar a roda, e fazer um sisteminha de mensagens com essas características. Eu fiz as mensagens acopladas a um perfil que eu criei pra o usuário do django, e não vou detalhar como se criar um perfil para seu User, veja mais aqui(lá no final do capítulo) e aqui.

Bem, basicamente é esse model:

class Action(models.Model):
    user = models.ForeignKey(UserProfile)
    action = models.CharField(max_length=200)
    pub_date = models.DateTimeField(auto_now_add=True)

    def __unicode__(self):
        return self.action

    class Meta:
        ordering = ('-pub_date',)
        db_table = 'auth_user_profile_action'

Onde a classe UserProfile, é minha classe que extende o User da aplicação contrib.auth do Django. Daí eu adicionei um método na classe UserProfile:

from django.contrib.auth.models import User

class UserProfile(models.Model):
    # meus campos extras
    user = models.ForeignKey(User, unique=True)

    # mais alguns método aqui, como o __unicode__, a class Meta, class Admin, etc

    def keep_actions(self, maximum=10):
        actions = self.action_set.count()
        if actions > maximum:
            extras = self.action_set.all()[maximum:actions]
            for extra in extras:
                extra.delete()

A intenção é a seguinte: sempre ter um número máximo de 'ultimas ações' do usuário, então esse método keep_settings() recebe um parâmatro opcional(valor default é 10), que vai ser o número máximo de ações que ele vai permitir na tabela. É mais um método pra "limpar" as ações antigas.

Um exemplo de uso:

def adicionar_foto(request):
    # codigo normal da view...
    profile = request.user.get_profile()
    profile.action_set.create(action=u'Foto adicionada')
    profile.keep_actions()
    profile.save()
    # termina a view normalmente....

Aí eu adiciono uma ação relacionada com meu usuário, e o método keep_settings() vai garantir que terá no máximo 10 "ultimas ações", caso tenha mais de 10, ele remove as mais antigas e deixa apenas as 10 mais recentes.

E no template ficaria assim:

<ul>
{% for action in request.user.get_profile.action_set.all %}
    <li>{{ action.pub_date|date:'d/m/Y H:i' }} - {{ action }}</li>
{% endfor %}
</ul>

Assim eu mostro a hora que a ação foi executada e deixo sempre um histórico de 10 ou mais últimas ações. Pra deletar todas poderia chamar o método keep_actions(0) passando zero como parâmetro.

Envolva-se no mundo Django

2008-01-31T00:00:00-10:00

Esse post vai pra quem ta começando no Django, e quer ficar mais ligado no que acontece por ai. Alguns sites, blogs listas de dicussão, pra aprender, tirar dúvidas e ver as novidades relacionadas ao Django.

O mais recente é o Django People, que é como uma rede social de djangers, onde você pode se cadastrar e encontrar outros djangers por perto ou em qualquer lugar do mundo. No momento que escrevo esse post, o Brasil está em segundo lugar em número de pessoas cadastradas, com 89, perdendo apenas para os Estados Unidos. :D. Eu também acompanho o feed do blog do criador do site, Simon Willisons

Tem o site da nossa comunidade nacional, Django Brasil. Lá tem o agregado de blogs de vários desenvolvedores pelo Brasil que usam Django. E também o blog oficial do Django Brasil. A documentação oficial está sendo traduzinda para o português. Tem também o DjangoBook, um livro que foi lançado recentemente, e está disponível online.

O DjangoSnippets é muito bom, são snippets que os desenvolvedores colocam pra comunidade. Sempre acho algo interessante aqui. Só sinto falta de uma caixinha de busca no site, mas se bem que toda vez que procuro algo lá por tag, linguagem, acabo esbarrando em alguma coisa boa!

Está procurando emprego em Django? Ou desenvolvedores? Cadastre-se no DjangoGigs!

Você já tem um site feito em Django? Cadastre ele no Django Sites, que já tem mais de 900 sites cadastrados! E coloque um logo do django no seu site também.

Tem também alguns projetos legais de aplicações para seu projeto:

django-diario , é um weblog plugável
django-tagging , uma aplicação de tags genérica
django-photologue , uma galeria de fotos
django-gadgets , para desenvolver Google Gadgets

A pouco tempo tava procurando como reproduzir videos em flash nos sites, e achei dois links interessantes:

A lista de discussão é bem movimentada, felizmente a comunidade nacional de Django está crescendo muito. Participe no canal #django-br na Freenode também, e no #django. Além das listas internacionais: django-users e django-developers

Não me lembro de mais links interessantes pra passar, caso alguem tenha mais, vou adorar adicionar no meu del.icio.us. :)

Django no Jython

2008-01-30T00:00:00-10:00

Django irá rodar no Jython 2.5, que será sua próxima versão, compatível com a 2.5 atual do CPython.

Atualmente ainda precisam de alguns hacks pra funcionar, e ainda tem algumas funcionalidades quebradas, como por exemplo o servidor de desenvolvimento tem que ser inicializado com --noreload.

Veja mais detalhes: DjangoOnJython Python Web Framework on the JVM

Conjuntos em Python - set e frozenset

2008-01-20T00:00:00-10:00

Os conjuntos são um tipo de dados do python que nunca ouvi falar muito. Eu particularmente nunca usei, mas dando uma olhada agora vi que são muito interessantes.

Uma coisa que eu precisei fazer ontem foi retirar dados repedidos de uma lista, e não existe um método de lista que faça isso. Já nos conjuntos isso é automático, não existem dados repetidos.

A diferença entre set e frozenset, é que o primeiro é mutável, já o segunto não. Criando um conjunto...

>>> conjunto1 = set('12345')
>>> conjunto1
set(['1', '3', '2', '5', '4'])
>>>

Veja que é passado um tipo iterável para o set(nessa caso uma string), onde cada elemento vai ser um elemento do conjunto.

>>> conjunto2 = set([4,4,7,7,8,9])
>>> conjunto2
set([8, 9, 4, 7])

Veja que realmente ele não permite elementos repetidos. Você deve ter percebido que os elementos não estão na mesma ordem que foram passados. Isso porquê conjuntos realmente não possuem nenhuma ordem. São iteráveis, ou seja, podemos fazer for x in meu_conjunto, len(meu_conjunto), x in meu_conjunto. Mas como eles não possuem ordem, não é permitido indexação, nem slicing, algo tipo meu_conjunto[2:] está errado.

Mas vamos a algumas operações entre conjuntos.

Está contido e contém

>>> conjunto1.issubset(conjunto2)
False
>>> conjunto1.issubset(set('123456789'))
True
>>>

Também podemos usar os operadores

>>> conjunto1 <= set('123456789')
True
>>> set('123456789') >= conjunto1
True

União

>>> conjunto1.union(conjunto2)
set([4, 7, 8, 9, '1', '3', '2', '5', '4'])
>>> conjunto1 | conjunto2
set([4, 7, 8, 9, '1', '3', '2', '5', '4'])

Interseção

>>> set('123').intersection(set('345'))
set(['3'])
>>> set('123') & set('345')
set(['3'])

Diferença

>>> set('1234').difference(set('3'))
set(['1', '2', '4'])
>>> 
>>> set('1234') - set('34')
set(['1', '2'])
>>>

Operações entre sets e frozensets são permitidas, mas veja que a ordem em que eles aparecem importa

>>> set('234') | frozenset('45')
set(['3', '2', '5', '4'])
>>> frozenset('23') | set('567')
frozenset(['3', '2', '5', '7', '6'])

Outra coisa importante, é que podemos passar iteráveis tanto na criação do set como nas operações usando os métodos. Mas as operações usando os operadores devem ser obrigatoriamente entre sets:

>>> set('234').union([5,6])
set(['3', '2', '4', 6, 5])
>>> 
>>> set('234') | [2,3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for |: 'set' and 'list'
>>>

Os sets, por serem mutáveis, também possuem métodos que adicionar e remover novos elementos. Como os frozensets são imutáveis, não possuem esse métodos

>>> conjunto1 = set(['a','b','c','d'])
>>> conjunto1
set(['a', 'c', 'b', 'd'])
>>> conjunto1.update(set('nada'))
>>> conjunto1
set(['a', 'c', 'b', 'd', 'n'])
>>>

O conjunto.update(outro_conjunto), atualiza conjunto adicionando os elementos de outro_conjunto. Tem também os métodos set.add(x), set.remove(x), set.pop(), set.clear(). Além do set.discard(x), que só remove o elemento se ele existir, diferente do remove() que retorna KeyError caso o elemento não exista.

O exemplo que eu citei no começo, de retirar dados repetidos de uma lista poderia ter sido feito assim:

>>> numeros = [2,5,3,2,1,6,3,5,2,2]
>>> list( set(numeros) )
[1, 2, 3, 5, 6]

Simples não?

Veja mais detalhes sobre conjuntos aqui

Novo blog em Django

2008-01-15T00:00:00-10:00

Nos últimos meses eu tenho brincado com Django, e estou achando muito bom, o desenvolvimento é bem ágil, afinal é Python! Testei o TurboGears também no começo, mas Django me atraiu mais...

Acabei de terminar esse blog, feito em Django. Por isso vou descontinuar o defpython, vou deixar ele lá pois tem uns artigos legais, mas só vou atualizar esse aqui agora. E outra coisa que eu achava meio chato, era que o defpython tinha a finalidade de falar sobre Python, então eu evitava postar sobre outros assuntos, outras linguagens, etc. Mas aqui vai ter de tudo um pouco, com um feed específico pra cada categoria também.

Por enquanto é só. Pra quem ainda não conhecia Django, o pessoal da comunidade Django Brasil está fazendo um ótimo trabalho traduzinho a documentação oficial, é o melhor lugar pra começar.

Igor Sobreira

Testing infinite loops

Conclusion

Start simple

Why not make a dict subclass?

Conclusion

Unnecessary classes

Use functions

Use builtin data structures

References

Python coverage threshold

Improving performance of Django test suite

Vagrant plugin to take screenshots

Book review - Being Geek

Command line interface to FMS Admin

Change object after saving all inlines in Django Admin

Adding methods dynamically in Python

Adding methods to builtin types

Mocks, Stubs, Fakes and Spies

Extending the User model in Django

Extending using foreign key

Why subclassing User is a bad idea

Editing User profile in admin

Conclusion

Slides - Desenvolvimento web com Python e Django

Campos numéricos localizados no Django

Difference between _, __ and __xx__ in Python

One underline in the beginning

Two underlines in the beginning

Two underlines in the beginning and in the end

Conclusion

Customize settings.py locally in Django

Use the --settings option

Importing from settings.py

Adding code dynamically to settings.py

Host specific settings

Conclusion

Replacing render_to_response with direct_to_template in Django

Django readonly fields in Admin

Python 3.1.1. error on startup

Ajax File Upload with jQuery

Usage

Download

1º Encontro do GrupyPB

Skype derrubando conexão

Suprimir DeprecationWarning

Estruturas de dados do Django

Python weakref

Customizando o prompt interativo do Python

MySQL-python no Mac OS

Properties no Python 2.6

mod_wsgi no OSX

Django 1.0!

Auto-complete no Django

Palestra sobre Django no ECD

Novo usuário Gentoo!

Construtores e Destrutores em Python e PHP 5

Linux com cara de Windows

PIL - IOError - decoder jpeg not available

Programando em Java no Gedit

II Encontro do Comunicação Digital

Mensagens para os usuários no Django

Envolva-se no mundo Django

Django no Jython

Conjuntos em Python - set e frozenset

Novo blog em Django

Difference between _, and xx__ in Python