Archive for Python

Django/Dojo Stammtisch in Berlin

For the second time Django enthusiasts are meeting in Berlin on Wednesday, the 15th April, 2009 at 19:30. Find all the details here. And since I will be in Berlin this time, I just simply redeclare this to “Django/Dojo Stammtisch” instead of just “Django Stammtisch” :-). I hope all the djangoers are ok with that (I requested permission in #django-de). It just makes things easier to also meet some dojo people in Berlin. I will also have some cool new dojango stuff to show off!
So if AJAX, JavaScript and Dojo people are around, it would be cool to meet you there and chat about what’s hot and how the beer is. Please add yourself to the attendees list on doodle. And thanks again to the Berlin djangoers for organizing this, I am looking forward to it.

I cross-posted this from the uxebu blog, please go there to comment on it.

Comments (2)

dojo.beer(2)

We from uxebu have organized the second dojo.beer and are happy to have won Mayflower to jump in sponsoring the location here in Munich, Germany. On friday the 5th december we will warm up with some dinner and some beer in some place here in Munich. The real thing will be on the 6th at the Mayflower office, doors will be opened at 12:00 and we are hoping for a lot of talks from various people, to see how the are using dojo and we are also hoping to have interesting talks providing some useful input and may be even new stuff to learn. Bring your laptop and let’s hack away. If you have something special you need to have solved there will be someone who can help, for sure. From beginners to experts everyone is welcome. You don’t know nothing about dojo yet, but are interested you are right at the dojo.beer. You are a long time dojo user and want to dive into the depths of dojo, you are also perfect at the dojo.beer. So let’s have a great time and join us at the dojo.beer().

Some selected topics will (hopefully) be: functional programming with dojo, i18n, dojango, dojo build, dojo+Adobe AIR, deft - the dojo experimental flex technology, dojo and Zend Framework and many more.

Find all the details here dojo.beer.mixxt.de.

Comments (1)

Customize admin for User model

Before django 1.0 I don’t remember that there was a way to customize how the admin renders the User overview. Fortunately 1.0 does allow it.
It took me a bit to figure out. After searching the web and the django docs I didn’t find it right away, so I tried the normal fallback: auto-completion (WingIDE does that really good).
Normally if you just define your own UserAdmin class in admin.py, like this:


class UserAdmin(admin.ModelAdmin):
    list_display = ('username', 'email', 'first_name', 'last_name', 'date_joined', 'last_login')
    search_fields = ['username', 'email']
admin.site.register(User, UserAdmin)

You get the following error when starting up the server:


django.contrib.admin.sites.AlreadyRegistered:
    The model User is already registered

Well, as I said, the auto-completion just made me come across it pretty quickly, and it is so logical. Simply unregister the admin class for User before redefining it :-).


class UserAdmin(admin.ModelAdmin):
    list_display = ('username', 'email', 'first_name', 'last_name', 'date_joined', 'last_login')
    search_fields = ['username', 'email']
admin.site.unregister(User)
admin.site.register(User, UserAdmin)

Done. Cool, ha?
Congrats to all the people behind Django 1.0, good stuff!

Comments (5)

dojo+django = dojango (just released)

Finally we have released dojango. Well, to be honest it’s mostly Tobi’s work that dojango rocks as it does! Big thanks!
So if you are still looking for the right JavaScript toolkit to go with django then you are at the end of your search now. Use dojango! Dojango s

  • a reusable django app that provides dojo
  • easy dojo setup inside django
  • build an optimized dojo
  • some helper functions, i.e. JSON conversion
  • switch easily between different dojo versions.

You find the project homepage right here.

Comments (5)

Adobe Air Tour Europe stopped in Munich

Fortunately Tobias found out one day before that Adobe was touring with Air and coming to Munich. Adobe really had provided everything, from breakfast, drinks, lunch too I guess (we weren’t there) and beer afterwards (that we didn’t miss). It was really impressive. The talks were very Air focused, I liked the first one best, which gave an overview of what Adobe does and plans to do. One of the notable things was to see VoIP running inside a flash client, pretty nice. The Air stuff was just nothing too new and I see the main focus of using Air in running JavaScript+HTML apps inside it, so I was actually more interested in what is different to web apps in this concern. And Dion held a very nice overview talk about his employer’s latest product AppEngine, which was very interesting to see too, since I am a django addict too.
But anyways, besides my personal interests, I think Adobe had arranged a great event and the sessions had been very well received. Congrats Adobe. it was fun.
The best part for me was meeting with Dion Almaer the Ajaxian man, finally getting to know the person behind the voice, since I am an avid podcast listener I have heard all of the ajaxian podcasts too. If you ever have him near go and talk to him, a very nice person!
It was also nice talking to Andreas Ecker project lead of qooxdoo, he showed me what will be coming next in their new version. But you know, I am already married ;-). Even more interesting because we had been colleagues for a while last year.
And Adrian Ludwig from Adobe stopped me when he saw the “dojo” on my shirt and we talked some dojo+Air. Adobe is very interested in staying in touch with the AJAX community. It just simply seems that the Flash guys are coming across Air anyways, but the other potential users are all the AJAX devs. So I hooked him up with Nikolai right away, who I knew had been creating the nice Air demo over at dojocampus.

Comments (1)

A functional task, I am sure

Now that I dove into functional programming (only using dojo and python, but it’s a start) and feel that my brain has not completely made the switch yet, I come across problems that look like they are best to be solved with functional programming. Isn’t it always that way, when you have started something new and are still excited about it, that the every day problems seem that they want to be solved the new way? Anyway, here it goes.

I got this dictionary. The keys are IDs and the values are kind of a rank. Now I want to sort the IDs by their rank.
I am sure there is a simple one liner for that. But I didn’t come up with it yet.
I only came up with a quite dumb concat, sort and split solution. Not elegant at all.


d = {4: 6, 12: 4, 14: 14, 18: 16, 32: 6,
    33: 24, 40: 27, 41: 6, 44: 25, 106: 2}
d1 = ["%06d" % v+'_'+str(k) for k,v in d.items()]
# d1 is now something like this:
# ['000006_4', '000004_12', '000014_14', '000016_18', ...]
d1.sort() # That allows us to sort, which does it
sorted = [int(i.split("_")[1]) for i in d1 ]

This has several drawbacks, but it was as good as I got :-(.
I hope this has no negative effect on my career.

[Update] Thanks to Daniel’s second post, this is the solution!


sorted(d.items(), key=itemgetter(1))

Awesome, thanks!

Comments (5)

Python is still awesome

Just because I just came across it while optimizing some old code, I have to mention this.
I have the following list of dictionaries (array or hash-arrays in other words) and I want to sum up the values of one of the items of the dictionary.

In python I do this


    d = [{'value':1, 'title':'one'}, {'value':2}, {'value':3},
         {'value':4, 'title':'four'}, ]
    s = sum([i['value'] for i in d])

In PHP I would have done this (I guess)


    function extract_value($r) {
        return $r['value'];
    }
    $d = array(array('value'=>1, 'title'=>'one'), array('value'=>2),
               array('value'=>3), array('value'=>4, 'title'=>'four'));
    $s = array_sum(array_map("extract_value", $d));

Cracks come forward and shorten it please (in any language!).

Comments (27)

Mayflower Barcamp - awesome!

Mayflower had invited me to join their Barcamp last weekend - and it was awesome. Thank you a lot!!!
We had been a crowd of about 40 people all hacking all day long until deep at night, it was a great atmosphere and some very interesting projects had been made. I am sure some things will come up on the Mayflower blog soon, just keep watching!
I was mainly working on integrating the dojo.grid into the next version of Phprojekt and doing some ground work for a very flexible structure. And I have learned a lot more about dojo again. It’s just great!
Besides that I was advocating a lot for Python and Django especially :-), I just can’t hold back. But it’s hard to convert anyone there, since Mayflower is the biggest and best PHP service provider in Germany and the people there are really good in what they are doing! Though one came up to me and said “thank you for putting the Python book on the table” (which I did a while ago in the Mayflower office, just for fun).
Thanks again and hopefully see you soon again.

Comments

Django’s dev server and UTF-8

From time to time I got this UnicodeEncodeError, but I had done all the things (sitecustomize.py, some more) right in order to configure the system in UTF-8. I thought.

I did the usual

     ./manage runserver

and since I assumed that on my Mac everything is already properly configured to be UTF-8 I didn’t even think of the shell not being properly set up. Fortunately my colleague Tobi found out that I have to set the shell variable LANG=”utf-8″. So now I always do:

     export LANG="utf-8"
     ./manage runserver

So I went from the wrong locale output to the one working properly with UTF-8 and Django, jiha!

cain@home:~> locale
LANG=
...
cain@home:~> export LANG="utf-8"
cain@home:~> locale
LANG="utf-8"
...
cain@home:~> # now i can safely start Django :-)
cain@home:~> ./manage runserver

Comments (7)

json_encode() updated

[UPDATE] The link to the sourcecode now points to the dojango implementation, the dpaste one is gone.

Just in case someone is using json_encode() I wrote a while ago, I have updated the function due to updates in the latest Django dev version. Find the source here.

I have solved two problems here. One is that now lazy strings are used all over in Django, which this updates handles and detecting a list and a dictionary stumbled on subclasses of them.

Comments (2)

Doctests for dojo

Sometimes when you want to do something right and you are lacking the tools you write them (but very often I don’t :-) ), but in the case of doctests for dojo I saw the need. This time I took the time to write a doctest-class for dojo. It is currently only a ticket in the dojo trac, but some feedback looks pretty promising.

I saw the Ian Bicking had already once written a doctest module, but after skimming over it and thinking about the task, I decided to write it from scratch and a pure dojo fit, since it surely is not much work (as it also turned out, which is a rare case).
I knew the doctests module from the Python, where it obviously also comes from. In the beginning I found doctests ugly, those huge chunks of console-pastes inside my docstring. But after getting to know the value of the doctests by learning django’s newforms completely by a huge doctest I felt what they can do and that they can really help a lot.
Doctests just make you understand the code in the place it is written. If you (as I do) often look into the sources it can be really helpful to see a programming example right there inside the docstring of the class/method/function.

To make it short, I implemented this for JavaScript and it works nicely. I am actually developing a dojo.data-store but in order to do that I needed doctests, that’s where the need came from.
One of dojo’s base functions might look like this now:


dojo.trim = function(/*String*/ str){
	// summary: trims whitespaces from both sides of the string
	// description:
	//	This version of trim() was selected for inclusion into the base
	//	due to its compact size and relatively good performance (see Steven Levithan's blog:
	//	http://blog.stevenlevithan.com/archives/faster-trim-javascript).
	//	The fastest but longest version of this function is going to be placed in dojo.string.
	// examples:
	//	>>> dojo.trim(" trim me ")
	//	"trim me"
	//	>>> dojo.trim("\t\ttrim me ")
	//	"trim me"
	//	>>> dojo.trim(" \t\t trim me \t ")
	//	"trim me"
	//	>>> dojo.trim("trim me")
	//	"trim me"
	//	>>> dojo.trim(" trim me")
	//	"trim me"
	//	>>> dojo.trim("trim me ")
	//	"trim me"
	//	>>> dojo.trim("")
	//	""
	return str.replace(/^\s\s*/, '').replace(/\s\s*$/, '');	// String
}

You can see more examples here and here (search for the doctest starting with “>>>” and you will find some).
Below “examples” you can see the inline doctest. I really just wrote those tests in the FireBug console and copied them later into the code.

Run doctests
The trac ticket in dojo including the files and some info you can find here. You can download the patch right here.
First apply the patch, so that the dojox.testing.DocTest module is available.
This patch containing the doctest class is though to be a part of dojo, so it currently requires that you have a dojo module or a module that you registered with dojo (dojo.registerModulePath()).
To run i.e. the above shown doctest you just need to know in which file (module) it is (dojo._base.lang in this case) and type the following into your FireBug console:

>>> dojo.require("");
>>> var doctest = new dojox.testing.DocTest();
>>> doctest.run("dojo._base.lang");

It will then print out a line for each test in the FireBug console with the result and some info. In the before case it looks like this:

...
Test 44: OK: dojo.trim(" trim me ")
Test 45: OK: dojo.trim("\t\ttrim me ")
Test 46: OK: dojo.trim(" \t\t trim me \t ")
Test 47: OK: dojo.trim("trim me")
Test 48: OK: dojo.trim(" trim me")
Test 49: OK: dojo.trim("trim me ")
Test 50: OK: dojo.trim("")

Embed doctest
You can also embed the doctests into other test modules, i.e. if you are just want to add the doctests to your unittests and get them all as one result. You can simply check the property errors of your doctest instance:

>>> doctest.errors
[]

As you can see if there are no errors it’s length is 0.
You can see an example of how to do that here in the file data/tests/stores/QueryReadStore.js the first function testDocTests() runs the doctests of the module “dojox.data.QueryReadStore” and verifies that there are no errors.

I hope this will be useful to some people. Let me know if you have any kind of feedback, bugs or whatever. In the class itself you can see that I have also already thought of some things that need to be done/added to this class. Have fun doctesting …

Comments

Django sprinting in Augsburg (Germany) too

Tomorrow there will be a django sprint, we are meeting at Tobi’s place in Augsburg (Germany). If you are interested in joining just drop him at tobias at klpstn punkt com or me wolfram at kriesing punkt de an email. It would be great to see some more django people.
Please bring coke and chips, we are providing wide-band-high-speed-fully-privileged access to the entire world wide web!

Happy sprinting …

Comments (3)

Google Test Automation Conference 2007

The titles of the videos look very much like “must watch”. Found via ThinkPHP, thanks.

Comments (2)

Generate django project API docs

It was not as easy as I expected but I found it out. Creating the a django project’s API doc is pretty easy once you know how! Unfortunately there is a bug in the django integrated doc that you can reach via the admin interface by /admin/doc/ but it is also far less complete (if it would entirely work) than what a pydoc offers.

One problem with both tries the django admin doc and the pydoc was that we are using a lot of decorators for view functions. Decorators such as “login_required” or “transaction.commit_on_success” and the doc generators both either ignored those functions or linked wrong (django admin doc).

So I decided I want the real API docs and done, that is what most devs are best familiar with. But to get that you need to fiddle a little bit with the setup of django and export some variables in order to properly make doc generation work. We used epydoc for generating the docs, it throws out the nice frame-based javadoc like view, I find that quite handy.
Here is how it goes:

  1. export PYTHONPATH=$PYTHONPATH:/Users/wolfram/projectname/trunk/ - extend the python path so that it also find your project
  2. export DJANGO_SETTINGS_MODULE=projectname.settings - set the required django variable
  3. /Library/Frameworks/Python.framework/Versions/2.4/bin/epydoc --html --parse-only --docformat plaintext re -v projectname
    make epydoc generate the docs

epydoc will create a directory named “html” and put all the docs in there, open the index.html in your browser and you are all fine. Happy doc reading …

Comments (3)

Extend django’s User class

There are many days when I think that Python is pretty good, and there are a couple of days when I think Python is divine. Yesterday was one of them. Actually it was a pretty easy task, you just need to know how :-).

I am using django’s default class User that already comes with django. Now I wanted to add some methods to this class. Extending a django model is not the way to go, since that has a different meaning here.
So I got my class, that actually contains additional functionality that should go into the User class.


class UserFunctions:
    @staticmethod
    def get_shortcut(user):
        return "user#" + user.id
    ...

For a couple of days I was very unhappily using this class via static calls, like so:

u = User.objects.get(id=3)
UserFunctions.get_shortcut(u)

How ugly is that?!
That was pretty annoying, blew up the code, was not handy and it could not be used inside a template and many more drawbacks I guess. I needed something better!
So I thought about mixins, but never used them. Reading a bit online I found out that it should be as easy as:

User.__bases__ += (UserFunctions,)

Alright.
So I changed my UserFunctions class as follows and mixed it in :-).


class UserFunctions:
    def get_shortcut(self):
        return "user#" + self.id
    ...
User.__bases__ += (UserFunctions,)

Awesome! Now I can do the following.

u = User.objects.get(id=3)
u.get_shortcut()

And therefore I can also use those functions from within the template, etc, etc. …
That was one of the highlights of my day yesterday … but I guess most of you knew already how to do that :-)

Comments (14)

JSON serialization for Django improved and simplified

[UPDATE] It got updated due to some internal changes, see here.

A lot of times I have to serialize data into the JSON format, which by itself is actually no problem at all. I just found that django not really provides a perfectly working interface for that. Especially when you are working with django query sets, that need to be serialized. In this article I just want to show the problems I encountered and why I have written a tiny custom function to solve the task in a very simple way (you can find the alternative JSON serializer here).

An every day tasks
Using AJAX and all the hyped technologies nobody gets around not using JSON anymore. It is a very lightweight and very well readable notation, JSON integrates perfectly with JavaScript and is very quick transporting simple data. I really am very happy to have such an easy interface that connects my back-end services with the front-end.
Since django is reducing my code by so much I am often happy to write very short functions that provide data for a view. An entire view function that looks kind of easy as the following is not rare:


    def search_users(request, search_string):
        users = User.objects.filter(name__startswith=search_string)
        return util.json_response(users)

You can see that the JSON serializer (called from inside util.json_response) also has to be able to handle a queryset, the content of the variable users, properly. A QuerySet represents a collection of objects from your database. (from django doc)

How does django do that?
The documentation has a chapter about serialization, including JSON serialization. And it also tells there that this API might change in the future, so I am just using the latest which is from around version 0.96.
That is how the documentation suggests to do the serialization.


from django.core import serializers
serializers.serialize("json", queryset)

Looks quite simple. And that is what we all love about django, simple and effective code :-).

Django implements various serializers, therefore this functionality is abstracted out into various modules. I tried to enhance the current implementation to handle the problems I found (see below). Somehow I had the feeling that the current solution is very complicated for the simply task, that the integration of JSON serialization into django actually is. After playing around for a while I decided to write a small function that does the JSON integration. And it also should solve the problems I found, which I want to describe now.

Adding custom properties to querysets
I caught myself quite often adding some custom properties to a queryset and pass those data on to be serialized. Like the following:


    def search_users(request, search_string):
        now = datetime.now()
        users = User.objects.filter(name__startswith=search_string)
        for u in users:
            u.logged_in_for = now - u.last_login
        return util.json_response(users)

Unfortunately it looks like the django serializer only walks through the fields defined in the model and serializes them. So adding the extra field “logged_in_for” which contains the time for which the user is logged in now, would not be serialized using the django serializer. So that was one important task I needed the alternative serializer to fulfill.
Of course you could write a function that you tell which properties shall be encoded and build a new dictionary of it and so on, but why, if I could have it for free.

Problems with certain types
It seems that the django serializer has problems serializing certain types. A FloatField seems to be one.
I have a field in a model with: models.FloatField(max_digits=20, decimal_places=10) trying to serialize that brings the following result:


>>> serializers.serialize("json",result)
...
  File "/Users/cain/programming/django/trunk/django/core/serializers/json.py", line 51, in default
    return super(DateTimeAwareJSONEncoder, self).default(o)
  File "/Users/cain/programming/django/trunk/django/utils/simplejson/encoder.py", line 258, in default
    raise TypeError("%r is not JSON serializable" % (o,))
TypeError: Decimal("43.3251776800") is not JSON serializable

But that seems an easy task to do. Why does that not work. Actually I didn’t try to dive into the django serialization to find out, I just converted those fields to strings. That was an ugly unnecessary hack!

Foreign keys cause problems
I had a model with a couple of ForeignKeys and m2m fields, and for some reason the django serializer had no fun with them, it just threw out this:


>>> s = Subchapter.objects.all()[:10]
>>> serializers.serialize("json",s)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/Users/cain/programming/django/trunk/django/core/serializers/__init__.py", line 55, in serialize
    s.serialize(queryset, **options)
  File "/Users/cain/programming/django/trunk/django/core/serializers/base.py", line 44, in serialize
    self.handle_fk_field(obj, field)
  File "/Users/cain/programming/django/trunk/django/core/serializers/python.py", line 38, in handle_fk_field
    related = getattr(obj, field.name)
  File "/Users/cain/programming/django/trunk/django/db/models/fields/related.py", line 165, in __get__
    raise self.field.rel.to.DoesNotExist
DoesNotExist

Problem number three.

The returned structure is a bit to verbose, imho
The structure of the JSON object django’s serialization returned seems unnecessarily complex to me. It doesn’t just spit out the data, but also some meta information about the model. It wraps the actual data into an object with the name “fields”. Well, that is no real bug, but it was simply in the way for me and I just wanted a flat structure.

Alternative JSON serializer
I saw that for my purposes this django serializer is a dead-end, so I set down and wrote an alternative serializer (see the code here). And that was very simple! If the task would not have been a very easy one, I would definitely have sat down and fixed the existing code. But sometimes there is this feeling that tells me that there is a better way, especially when a current solution seems too complex.
Actually this serializer is already a couple weeks old, but since I use it every day and I always think “others might have the same problem” I finally decided to at least write about it, so people can decide if it is worth giving it a try.
If there is even interest in integrating this serializer into django directly, I would be happy to help. If not it will definitely stay in my toolkit until a better solution comes my way.

Comments (16)

Django trap with LIMIT queries

I started doing Django after the magic-removal, but there is some magic left (but mostly good magic) in it and it’s a good thing to be aware of it! Always dig deeper, that’s at least my motto.

The model used here is the following:


class Item(models.Model):
    id = models.AutoField(primary_key=True)
    name = models.CharField(maxlength=100)
    def __str__(self):
        return self.name

The LIMIT basics
Be sure to really understand what happens when you are using limit query, which is the array slicing syntax. Calling the following:
Item.objects.all()[2:4]
will execute this query
SELECT `core_item`.`id`,`core_item`.`name` FROM `core_item` LIMIT 2,2
BUT not until you are using the data. Using the shell is therefore sometimes a bit misleading, since calling the above results in printing the result, so it is being used at this moment, which inside a script would not be the case.

>>> Item.objects.all()[2:4]
[, ]

Here you can see that two items are being printed, right after the call, but that’s a shell thing, remember that!

Mixing slicing and LIMIT
If you mix the usage of the slicing operator and the limit query on a queryset you better know what you are doing. Let’s see first:

>>> items = Item.objects.all()[2:4] # Django basics, this is LIMIT.
>>> items[5] # Looks like it should be slicing, is LIMIT!


Ooops. How come? Why is there a fifth element at all? Let’s investigate a bit more! Is items not what we expect? How many elements does items contain? What is being returned, when calling the first line of the above?

>>> len(items)
2
>>> type(items)


Uhu, ok. The Django documentation does also explain that very well, so be aware, you don’t get a list returned, but a queryset!
So what is happening here in detail? This line >>> items = Item.objects.all()[2:4] clones a queryset into the variable items. So items is not a list, as the syntax might would let you expect, but a queryset! This assignment is actually only a method call. The method call to __getitem__() in django.db.model.query.QuerySet, this does finally return a cloned queryset with adjusted LIMIT parameters (effectively this is called self._clone(_offset=offset, _limit=limit)). So there is no query execution at this point.
And if the next call is now items[5] then the same method is being called again with LIMIT 5. So there is no slicing done here, as one would expect. This second call is also just a simple method call to __getitem__() and since the shell prints the result right away the query is actually being fired!

The work around
In order to make Django do what you expect you need to be more explicit than normally:

>>> items = list(Item.objects.all()[2:4])
>>> items[0]

>>> type(items)


This makes Django fire the query right away and return a real list, as you can see above. Now you can use the result as one would expect when reading it as normal Python code (without knowing that it is Django).
This has two effects: you are executing the query earlier and you have no QuerySet object anymore that you can work with. But that might be intended in this case.

Summary

>>> # next line fires: SELECT * FROM `core_item` LIMIT 2,2
>>> Item.objects.all()[2:4]
[, ]
>>> items = Item.objects.all()[2:4] # fires no query!
>>> # next line fires: SELECT * FROM `core_item` LIMIT 1
>>> items[0]


But

>>> items = list(Item.objects.all()[2:4]) # fires: SELECT * FROM `core_item` LIMIT 2,2
>>> items[0]


As I have mentioned above, you better know your tools! Django is very nicely using the overriding facilities that Python offers, but as usual, when you only scratch the surface you might be surprised and think “What is happening here” but don’t worry, the engine below is well thought through and really powerful! Let’s keep Djangoing …

Update
Thanks for Martina’s comment, which of course makes it much better! I modified the article accordingly.

Comments (5)

WingIDE and encoding

WingIDE tries to be clever and interprets the charset I use in my HTML file. So this makes it pretty happy:



But if I want to use this:


... content="text/html;charset={{ DEFAULT_CHARSET }}" />

It tells me:

Unsupported encoding ‘{{ default_charset }}’ found in encoding comment — Wing cannot write this file until the comment is changed

Well that is pretty funny. So I can’t use the Django setting to determine my charset.
Even turning off WingIDE’s file property “Use charset from file” (or what it is called) doesn’t help. Just in case someone is struggling too.

Comments (2)

Good to have: Universal Encoding Detector

By Mark Pilgrim, to get here http://chardet.feedparser.org/.

Comments (1)

Django and UTF8

I have to deal with it now and a lot of other people too, judging by the utf8/unicode/encoding topics on the django mailing list. I have found this one thread quite interesting and looks like the problem solver, but may be I also just need to learn a bit more about the bits and pieces that make this whole thing work. This message obviously tells how to make mysql completely aware and well-handling utf8.
Next thing on the list the django setting parameter DEFAULT_CHARSET.

Comments (2)