Как-то порка не задалась, а ведь очень есть за что. Я посмотрел только на файл code.google.com/p/recordbook/source/browse/trunk/recordbook/src/userextended/models.py
Здесь, правда, дико неудобно, окошко маленькое.
Но класс ClerkManager какой-то просто на удивление варварский.
Сейчас у меня все форматирование разъедется (на всякий случай dpaste.com/hold/67653/) и запускать я это не пытался, но
from django.db.models import Q
def search(self, str):
search_fields = ['last_name', 'first_name', 'middle_name', 'grade__long_name', 'grade__small_name']
search_query_list = [Q(**{s + '__contains': str}) for s in search_fields]
search_query = reduce(lambda x, y: x | y, search_query_list)
return self.filter(search_query)
кажется, работало бы лучше (search_fields можно перенести в атрибуты класса и передавать в конструктор; тогда этим менеджером можно было бы пользоваться и в других моделях).
Ну то есть черт с ним, с метапрограммированием. Но зачем там везде super(...)? Вы же не переопределяли метод get_query_set. Откуда же ему взяться, как не из суперкласса? И почему вы ходите в базу шесть раз? Ну первые пять еще как-то можно понять — не знаете про Q (без него очень плохо). Но зачем накапливать id и потом идти в базу еще раз? Почему не собрать сразу объекты?
Это не очень хороший код на Python. Например: зачем столько «self.» в «init»? Вы дальше этими атрибутами где-то пользуетесь? gtk.gdk импортируется, но нигде не используется. Зачем?
По-разному. В 7200 вроде действительно почти во всех есть, но это пока далеко не любой ноут. Ну и да — если это отдельное устройство, то его можно использовать для разных других дел и очень по этому поводу выпендриваться.
Это не IBM/Lenovo, это просто Lenovo. Разница в качестве Thinkpad по сравнению с тем, как было при IBM — очень заметная. У T43 клавиатуры не люфтовали.
(вообще в до-PC эпоху было не очень модно снимать фильмы по компьютерным играм)
Здесь, правда, дико неудобно, окошко маленькое.
Но класс ClerkManager какой-то просто на удивление варварский.
Сейчас у меня все форматирование разъедется (на всякий случай dpaste.com/hold/67653/) и запускать я это не пытался, но
from django.db.models import Q
def search(self, str):
search_fields = ['last_name', 'first_name', 'middle_name', 'grade__long_name', 'grade__small_name']
search_query_list = [Q(**{s + '__contains': str}) for s in search_fields]
search_query = reduce(lambda x, y: x | y, search_query_list)
return self.filter(search_query)
кажется, работало бы лучше (search_fields можно перенести в атрибуты класса и передавать в конструктор; тогда этим менеджером можно было бы пользоваться и в других моделях).
Ну то есть черт с ним, с метапрограммированием. Но зачем там везде super(...)? Вы же не переопределяли метод get_query_set. Откуда же ему взяться, как не из суперкласса? И почему вы ходите в базу шесть раз? Ну первые пять еще как-то можно понять — не знаете про Q (без него очень плохо). Но зачем накапливать id и потом идти в базу еще раз? Почему не собрать сразу объекты?
Других косяков в этом файле еще очень много.