October 30, 2008
Tags: Programming, Python
I recommend this very interesting read from Paul Graham regarding non-mainstream programming languages.
Quote:
It's a lot of work to learn a new programming language. And people don't learn Python because it will get them a job; they learn it because they genuinely like to program and aren't satisfied with the languages they already know.
Which makes them exactly the kind of programmers companies should want to hire. Hence what, for lack of a better name, I'll call the Python paradox: if a company chooses to write its software in a comparatively esoteric language, they'll be able to hire better programmers, because they'll attract only those who cared enough to learn it. And for programmers the paradox is even more pronounced: the language to learn, if you want to get a good job, is a language that people don't learn merely to get a job.
Makes you feel good for knowing Python...
[The Python Paradox via Corey Goldberg's blog]
August 16, 2008
In certain cases the Django generic views will behave like they are caching data. They are doing that for the queryset argument and not for extra_context which is known to be cached. This will happen if you send to the generic view a queryset filtered with a callable.
Let's take as an example a blogging application. In blog.models we have:
class PublishedManager(Manager):
def get_query_set(self):
queryset = super(PublishedManager, self).get_query_set()
return queryset.filter(pub_date__lte=datetime.now)
class Entry(models.Model):
...
pub_date = models.DateTimeField()
published = PublishedManager()
...
In blog.urls:
info_dict = {
'queryset': Entry.published.all()
}
entry_list = url(
regex = '^$',
view = 'django.views.generic.list_detail.object_list',
kwargs = dict(info_dict, paginate_by=10),
name = 'entry-list'
)
urlpatterns = patterns('', entry_list)
Internally, the generic view will _clone() the queryset sent in the info_dict, in order to get fresh data from the database. Unfortunately, at the time of the cloning, the queryset already has the filter applied with the datetime.now callable already invoked and the datetime value cached in the where clause. The generic view will always return the entries that have the pub_date less then or equal to the time when blog.urls module was loaded.
The work-around for this issue is to stop passing the queryset to the generic view through the info_dict dictionary. We can do that by creating our own view:
def entry_list(request, page=0):
return django.views.generic.list_detail.object_list(
request,
queryset = Entry.published.all(),
paginate_by = 10,
page = page
)
This way every time the view is called a new queryset will be created. This new queryset will always have in the where clause the current datetime.
Copyright © 2008 Mihail Ovidiu Pascut