kmike

Cразу на ум пришли ребята из www.revsys.com/ — они специализируются на PostgreSQL и там работают некоторые авторы Django.

По-нормальному — никак. Теги в одной строке раполагать. Можно регекспом в миддлвари вырезать, но это зло уже какое-то, похуже тега spaceless. См. code.djangoproject.com/ticket/2594

Можно еще Jinja2 вместо джанговских шаблонов использовать, если пустые строки очень напрягают, или джангу пропатчить (или проманкипатчить только нужные места) патчем из тикета. Или забить.

@unit1 правильное решение для общего случая описал. Конкретно в админке конкретно в этом случае можно чуть проще ('classes': ['wide'] в джанге уже определен):

class MyAdmin(admin.ModelAdmin):

    fieldsets = (
        (None, {
            'classes': ['wide'],
            'fields': ('name', 'slug', 'enabled')
        }),
        (u'Расположение', {
            'classes': ['wide'],
            'fields': ('address', ),
        }),       
    }

Насчет 3 — рекомендую профили привязывать через OneToOneField или AutoOneToOneField: это довольно прозрачная и простая схема (в отличие от наследования), к профилям можно получать доступ через user.profile1 и тд, + выбирать одним запросом что нужно и когда нужно через select_related (опять таки, никаких неявных запросов, как с наследованием). Причем get_profile() и AUTH_PROFILE_MODEL (или как его) непонятно даже и зачем использовать, скорее незачем.

Еще подумайте, вам точно нужна сущность «Account»? По сути же, насколько я понял, это просто кэш, чтоб из транзакций баланс не пересчитывать каждый раз. Вот и относитесь к ней, как к кэшу — те же подходы к инвалидации и тд. Может, даже пересчитывать каждый раз суммы на счете окажется ok, вы точно в это упираетесь по скорости?

Ну и, конечно, точка обновления счета должна быть одна: или какая-то явная функция, или по созданию Transaction пересчитывать значение в Account, или (imho плохо) по изменению Account создавать Transaction.

select_for_update есть в транке джанги. Для атомарного увеличения поля можно использовать F-объект (но лучше все пересчитывать целиком, опять же imho).

А чем вариант с инклудом плох-то? Используйте его.

использую django-timezones примерно так:

class City(models.Model):
    name = models.CharField(u'City', max_length=30)
    timezone = TimeZoneField(u'timezone')

    def now(self):
        return datetime.now(self.timezone).replace(tzinfo=None)

А потом, зная текущее время в городе, можно уже нужные любые вычисления проводить — просто вместо datetime.now() использовать что-то вроде self.city.now().

Все дополнительные навороты из django-timezones показались не очень полезными, не придумал, как их использовать можно — там дьявол в деталях, как обычно. Дополнительные расчеты можно проводить с помощью стандартного datetime или (и) стороннего dateutil.