Jul 8 2011

PyDev – automated refactoring problems

Béres Botond

Update: This has been resolved in PyDev 2.2.1!

My usual development tool for Python and Django projects is Eclipse + PyDev. This combination is pretty powerful, I’ve been using it for a long time and I like it, but there are some pain points that I wish would be improved upon.

For example PyDev’s automated refactoring support could use some improvement. I’ve just noticed the following “fail” when applying Extract Local Variable on some instance variable data like self.data['0']['values'] below. After extracting and assigning it to a local variable, it will just rename the first occurrence of self.data['0']['values'], in the same function!.

Before

def do_something(self):
 self.instance_method(self.data['0']['values'])
 
 ...
 
 self.another_instance_method(self.data['0']['values'])
 self.yet_another_instance_method(self.data['0']['values'])

After

def do_something(self):
 values_node = self.data['0']['values']
 self.instance_method(values_node)
 
 ...
 
 self.another_instance_method(self.data['0']['values'])
 self.yet_another_instance_method(self.data['0']['values'])

Now I understand that the reason for this must be that we are talking about an instance variable. PyDev cannot know for sure if in the section we modify the value of our instance variable indirectly or not. Or maybe another_instance_method modifies/overwrites it and then replacing all occurences would be a bad idea. Of course changing instance variables like that is a very bad practice but PyDev cannot know if we are using best practices or not in our code logic, so it stays on the safe side.

However, when doing the Extract Local Variable refactoring, it would be simple to have an option of  also replacing all occurrences or not. Let the programmer decide! I believe that’s the correct solution in this case and exactly what PyCharm does in this situation. So that’s a +1 point to PyCharm for this. I realize this is just one small bonus point to PyCharm, I’ve been playing around with it for some time and looks like a really nice IDE, but I’m not quite convinced yet if it’s completely superior to Eclipse + PyDev. We’ll see …

Which one do you like better? Or what other IDE are you using and how does it compare to Pydev/PyCharm?


May 4 2010

Add foreign key constraints in South migration

Béres Botond

Recently I needed to do something specific in a migration. I wanted to add foreign key constraints, but without any other change to models. Basically there was no change to “frozen” models, those were already correct, but somehow the database itself was missing a constraint (legacy database – app has only been converted to South fairly recently). I wanted to avoid raw SQL if possible, but initially looking at the docs I saw a db API method for deleting FK constraint but not for adding one. But after a quick look at the source it turns out there is a simple method:

def forwards(self, orm):
        sql = db.foreign_key_sql('from_table', 'from_field', 'to_table', 'to_field')
        db.execute(sql)
 
def backwards(self, orm):
        db.delete_foreign_key('from_table', 'from_field')

By the way if you develop applications with Django and are not using South yet (or at least some other migration tool), you better check it out, as it is currently the most up to date and stable migration app for it.


Apr 29 2010

Dynamic translation with django-datatrans

Béres Botond

A couple weeks ago I’ve faced the task of adding full i18n support to a large django project, with a lot of legacy code.  Besides dealing with full static i18n coverage, which is not really difficult just tedious and time-consuming, there remained the matter of translating texts stored in the database,  for a lot of models. I expected this to be non-trivial, given my desired requirements:

  • No significant changes required to existing code (ex. querying data, form processing, referring to model fields etc.).  Querying of data based on current language should be transparent.
  • Has a decent interface so that normal users can fill out translations.
  • Ideally it should be fairly recently updated and working well with Django 1.0 – 1.1.
  • Also as few changes to models and/or database structure as possible.  So most likely an app that implements the registration pattern.

What I love about django, besides django itself, is the fact that it has a strong and active community that produces many very useful and stable 3rd party apps.  So the first step was to look around for dynamic translation apps and sure enough there is quite a few of them out there. This great article provides an excellent overview of existing dynamic i18n apps for django. Unfortunately most of them are outdated or do not look too promising. Only one that looked like it could be  a candidate to be deployed on a production environment was django-modeltranslation at first. But then I noticed django-datatrans in the first comment, a fairly new app by Jef Geskens and it soon became the top pick. Although django-modeltranslation is also a good option,  I didn’t like the fact that it adds extra fields for each language on each model, even if it’s done dynamically with registration pattern. Especially that I had a lot of models to work with.

With django-datatrans you have your translations in a single table so your existing database structure is untouched. It’s also stored by hash, so you don’t have multiple records for the same string. The transparent model API works perfectly, I’ve encountered no issues at all so far, after applying it to 50+ models , nor did I have to modify a single line of existing code to make it work. The admin-like interface for editing your translations also will fit most needs, although there is some room for improvement there.  So if you need to translate some of your dynamic data as painlessly as possible, I strongly suggest you check out django-datatrans.