• 0
    Занятно то, что чтобы она произошла, нужно добавить в словарь больше элементов, чем в нем было. Иначе никак.
    Реализация словаря в Python 2.7
  • 0
    Занятно, что удаление элементов из словаря не приводит к уменьшению таблицы:

    In [1]: d = dict.fromkeys(range(9999))
    
    In [2]: d.__sizeof__()
    Out[2]: 786680
    
    In [3]: for k in xrange(9999):
       ...:       del d[k]
       ...:     
    
    In [4]: d.__sizeof__()
    Out[4]: 786680
    
    
    Реализация словаря в Python 2.7
  • +3
    Но в данном случае переменная var передаётся в шаблон slave.html неявно — var передатся в master.html, а slave.html просто «цепляет» контекст master'а. Таким образом, мы видим, что шаблон внутри {% include %} зависит от контекста основного шаблона. Мы вынуждены следить за контекстом родительского шаблона, иначе в дочерний может попасть что-нибудь не то.

    Решается параметром only:

    If you want to render the context only with the variables provided (or even no variables at all), use the only option. No other variables are available to the included template:
    {% include "name_snippet.html" with greeting="Hi" only %}
    Django tips & tricks
  • 0
    И? Если стоимость одного запроса в два раза больше стоимости другого запроса, это не значит, что первый запрос будет выполняться в два раза медленней. Можно неоптимально прописать эти константы, и никакой зависмости не будет. Что я пытаюсь сказать уже второй комментарий.

    единица измерения осталась та же

    А если в seq_page_cost прописать 3.14, то какой, по-вашему, будет единица измерения?
    Оптимизация запросов. Основы EXPLAIN в PostgreSQL
  • 0
    Не граничит оно никак со временем. Cost зависит от количества операций и их условной стоимости (planner cost constants). Эти константы, по уму, должны зависеть от особенностей машины, где работает постгрес (например, random_page_cost — разная для разных типов дисков, а effective_cache_size зависит от количества доступной памяти). В результате из всех возможных планов выбирается план с наименьшей стоимостью. А время тут ни при чем.

    В принципе, при грамотном выставлении planner cost constants теоретически можно добиться того, что cost будет прямо пропорционален затраченному времени, но сама по себе эта связь не обязательна.
    Оптимизация запросов. Основы EXPLAIN в PostgreSQL
  • 0
    Неясно, почему бы не сделать нормальный перевод. Зачем выкидывать кучу деталей из статьи, ориентированной на новичков? Один пример:

    Такой запрос будет исполняется реально. Так что если вы выполняете EXPLAIN (ANALYZE) для INSERT или UPDATE, ваши данные изменятся. Будьте внимательны! В таких случаях используйте команду ROLLBACK.

    Во-первых, без оборачивания в транзакцию от ROLLBACK не будет никакого толка, а во-вторых, ни слова про команду DELETE. Она не изменит данные что ли? Конечно, вещи очевидные, но не для новичков же. А не новички ничего нового не узнают (и им тем более нужны детали). В оригинале, при этом, все ок.

    Или еще: «width — средний размер одной строки». В попугаях? Опять надо лезть в оригинал (там все ок).

    Сколько строк будет считывать ANALYZE — зависит от параметра default_statistics_target.

    В оригинале — 300*default_statistics_target. Четкая и простая зависимость.

    Неясно, зачем портить статьи. Советую всем прочитать оригинал.

    Оптимизация запросов. Основы EXPLAIN в PostgreSQL
  • 0
    Ну может быть (хотя как он на эту страницу попадет, введет URL руками?). Плюс, таких ситуаций должно быть несколько, тогда подобная заготовка декоратора будет иметь смысл.
    «Декораторы проверки» для Views
  • 0
    В Джанге уже есть user_passes_test. Поэтому ваш should_be_anonymous реализуется одной строчкой.

    @user_passes_test(lambda u: u.is_anonymous(), login_url=reverse_lazy('my_view_name'))
    def some_view(request, *args, **kwargs):
        pass
    


    (Хотя имя login_url здесь выбрано не очень удачно).

    Какие еще условия, кроме проверки пользователя, можно привязать к request, я не могу придумать. О, можно проверять метод HTTP, например допускать только POST. Но Джанга у тут уже обо всем позаботилась.
    «Декораторы проверки» для Views
  • 0
    Этот тег отлично наследуется, так что достаточно одного раза в базовом шаблоне. Но даже если вы уверены, что middleware чище, почему бы не использовать django.utils.html.strip_spaces_between_tags, зачем писать эту логику самостоятельно?
    Упрощая жизнь c Django
  • 0
    Хм, а в чем именно сомнительность? Всегда был уверен, что куча маленьких узкоспециализированных аппов лучше одного монструозного.

    Еще, по поводу StripWhitespace middleware. Чем {% spaceless %} не угодил?
    Упрощая жизнь c Django
  • +1
    Зачем все это в одном пакете? Почему не в нескольких? Вообще же никакой связности.
    Упрощая жизнь c Django
  • 0
    Если функция load_template ничего не найдет, то она зачем-то вернет строку из одного пробела. Которая приведется к True, а не к False, как, видимо, ожидал автор.

    Рекомендуется к прочтению.
    Django своими руками часть 1: Собираем шаблоны для jinja2
  • 0
    Если проще, то так

    module, file = t.split(":", 1)
    
    Django своими руками часть 1: Собираем шаблоны для jinja2
  • +1
    Можно пару примеров, какие задачи поможет решить «умение программировать»?
    Программирование для всех: новый стандарт грамотности
  • +1
    Хорошая статья для Робинзона, вернувшегося в цивилизацию.
    Информационное пространство
  • 0
    Так инвалидация будет удобней, но станет более «жадной», о чем и сам автор пишет.

    For example if you update a post in a particular category, this strategy will expire all the keys for all the categories.


    Чаще всего это нежелательно. Хотя, можно группировать ключи более «гранулярно». Впервые я услышал о подобном подходе к организации ключей в этой прекрасной презентации.
    Еще о кэшировании в Django
  • 0
    Что ещё нужно-то? :-)

    Я приводил пример в посте. Часто, если в обработчике сигнала created == True, можно не инвалидировать часть ключей. Например, условно, топ100 статей за все время, свежесозданная статья туда не попадет. Есть и еще ряд проверок, которые могут оказаться очень полезными, чтобы не делать сложные выборки.

    И я не утверждаю, что это нужно всегда. Но что это есть, знать стоит, и учитывать при выборе подхода к кэшированию тоже стоит.

    По-моему, Вы как раз и пишете, что обновлять данные в кеше не стоит, т.к. операция неатомарная.

    Немного не о том. Я про то, что часто лучше заменить cache.delete(key) на cache.set(key, instance), если instance передается в сигнал.

    В целом, спор кажется бесперспективным. Я же не говорю: не используйте готовое, пишите все сами, только хардкор и т. д. У готовых решений есть некоторые ограничения. Если они критичны (или есть какие-то другие причины), то можно рассмотреть возможность реализации кэша самостоятельно. Если не критичны, конечно, используйте готовое. Только и всего.
    Еще о кэшировании в Django
  • 0
    Не очень понимаю, как это закрывает пост. К этому приложению применимы все те же две претензии:
    • Недостаточный контроль за инвалидацией: можно инвалидировать объект, можно инвалидировать все объекты модели, больше ничего.
    • Ограничения, возможно, потребующие дополнительного кода (раздел Caveats)


    Плюс, инвалидация только через удаление записи в кэше, что не всегда является лучшим решением (о чем я пишу в посте).

    Приложение хорошее, да, не хуже тех, что перечислены в посте, но у меня не было цели сделать обзор всех готовых решений. Так что может рано пока закрывать? :-)
    Еще о кэшировании в Django
  • +4
    Ну так это прекрасная новость. Вы очень продуктивно работаете с текстом и без всякого Вима. И Вим вам не нужен. Как бонус вы экономите месяц времени, который можете потратить на другие, более полезные дела.

    Никто ж не говорит «Вим — в каждый дом». Кому нравится — тот пользуется, кому не нравится — тот не пользуется. Мне нравится.

    Что касается вашего примера, то мне, например, неприятно было бы жать 10 раз вверх, а потом 20 раз вниз (держа шифт). А вот мозговых усилий мне как-то не жалко. Каждому — свой инструмент.
    ТОП-10 подводных камней, на которые вы можете наткнуться при переходе на Vim
  • +5
    Еще удобно удалять по номерам строк. Чтобы удалить с 5-й по 10-ю (включительно):

    :5,10d
    ТОП-10 подводных камней, на которые вы можете наткнуться при переходе на Vim
  • 0
    Скажите, пожалуйста, чем плох следующий велосипед. Выбираем некий шаг, например, 5%. Выбираем элементы, где процент положительных оценок ⊂ (95—100]. Сортируем по количеству положительных оценок. То же — для диапазона (90—95]. И так далее.

    Чем меньше шаг, тем выше точность. Из плюсов вижу интуитивную понятность, какие минусы?
    Как правильно сортировать контент на основе оценок пользователей
  • +5
    История #N.

    Мартин понял, что неделька будет еще та, когда руководство уже в понедельник забегало по офисам, говоря о чем-то на повышенных тонах. Очевидно, случилось нечто хреновое.

    “Мартин, — раздался голос начальника, заходящего к нему в кабинет. – Нам нужно поговорить. Это насчет того хренового происшествия”.

    Мартин зашел в кабинет начальника и, удостоверившись, что его никто не слышит, признался, что тут ничего нельзя поделать.

    Начальник был раздосадован, но Мартин объяснил, что их текущее решение никуда не годится, так что все логично.

    “Ах, если бы использовали решения компании NetWrix”, — вздохнул Мартин.

    “Да, Мартин, да”, — согласился начальник.

    Какие возможные решения существуют, чтобы не допускать такого впредь?

    Дисклеймер: У NetWrix имеются такие решения.
    История №1 «Полуденный вор» (из «5 историй об информационной безопасности»)
  • +1
    Итерации — это инструмент. Который может хорошо подходить для решения задачи, а может и плохо. Это, впрочем, относится почти ко всем вещам, которые «рулят».

    Во-первых, нужно «сразу спланировать большую и сложную систему решения задачи» в случае, когда у нас нет второй попытки. Например, так можно готовиться к сложному экзамену, собеседованию, публичному выступлению, военной операции, видеосъемке единичного явления и кучи других вещей. Во-вторых, когда цена каждой новой итерации слишком высока — планирование бюджета страны, например. Это с ходу, если хотите, придумаю и «в-третьих», и «в-четвертых».

    Возьмем человека, который мечтает выучить английский язык. Он пытается сразу взяться за чтение книг или фильмов, осознает, сколько ему нужно трудиться, и бросает задачу. Задача кажется неразрешимой и большой.

    В то же время, используя подход одного дня, о котором я писал ранее, и данный подход итераций, можно решить данный вопрос.


    Давайте лучше возьмем ребенка, который хочет научиться играть на пианино. Он идет в музыкалку, где все плевать хотели на какие-то итерации, и, о чудо, выучивается хорошо играть. Это, кстати, в-третьих: когда существуется многократно проверенный неитерационный подход решения типовой задачи.

    И еще, причем тут шахматы? В шахматах как раз и нужно «сразу спланировать большую и сложную систему решения задачи», причем в двух смыслах: как план игры и как конкретные варианты. Если, конечно, это не адский блиц и играешь серьезно. Можете показать, как можно играть в шахматы итерациями?
    Умение просчитывать
  • 0
    Вот и вот хорошие способы выйти «за рамки базы» в Last.fm
    Рекомендательные системы: постановка задачи
  • +5
    Ладно, это уже начинает надоедать. Остается только порадоваться, что есть-таки люди, которые в ладах с логикой и мыслят прямолинейно. Иначе мы бы до сих пор охотились на мамонтов.
    Мужская психология в программировании
  • 0
    «Если вы считаете, что логика может быть только та, которой учат в техническом вузе на, то вы ошибаетесь». :-)
    Мужская психология в программировании
  • +1
    Ок, откуда следует это? Как это вообще коррелирует с многозадачностью?
    Мужская психология в программировании
  • +4
    Во-первых, это не факты. Я вам уже третий раз говорю, что на мамонтов не охотились в одиночку, а вы упорно продолжаете звать свое незнание фактом.

    Во-вторых, я вас третий же раз прошу объяснить, почему «эти факты приводят к описанным выводам». Я ведь готов признать, что вы используете логику, которой нигде не учат. Я готов признать, что мыслить тут надо не прямолинейно, а по какой-то особой траектории, ок. Но объяснить-то можно?

    Откуда вы взяли, что мужчине нужно работать одному?

    Вот из этой вашей фразы: «обеспечьте программисту возможность в течение долгого времени быть одному и не отвлекать его от работы». Кстати, опять же без обид, фраза неграмотная, «обеспечьте программисту возможность… не отвлекать его от работы» (или «обеспечьте программисту возможность… и не отвлекать его от работы»).
    Мужская психология в программировании
  • +6
    Ок, обменялись впечатлениями друг о друге, теперь по существу.

    Почему из того, что надо долго готовиться, следует, что мужчина не может выполнять несколько дел одновременно?

    Почему из того, что мужчина не многозадачен, следует, что ему надо работать одному?

    Как это согласуется с историческим фактом, что на мамонтов охотились коллективом?
    Мужская психология в программировании
  • +12
    Без обид, но по-моему у автора сильные проблемы с логикой.

    Чтобы охотиться, мужчина очень долго готовился, точил топор, готовил стрелы и лук. Потом он долго сидел в засаде и наконец делал выстрел или наносил удар. Эта особенность поведения трансформировалась и дожила до наших дней… В отличие от женщины мужчина не может выполнять несколько дел одновременно.

    Где здесь связь? Почему из того, что надо долго готовиться, следует, что мужчина не может выполнять несколько дел одновременно? Может быть он одной рукой точил топор, а другой — готовил стрелы?

    Отсюда следует 1-й вывод: обеспечьте программисту возможность в течение долгого времени быть одному и не отвлекать его от работы.

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

    После долгого сидения охотник показывал чудеса доблести и отваги. 2-й вывод: обеспечьте возможность признания достижений программиста внутри организации. Необходимо организовывать периодически сборища, где программисты будут обсуждать технологии и показывать себя перед другими.

    Опять же, как это выводится? Как из «Петя увидел черепаху» можно вывести «Обязательно хвалите Петю каждый раз, как он видит черепаху»?..

    Если слишком долго готовиться, то мамонт убежит.

    У вас мужчина сидит в засаде. Куда от него убежит мамонт?

    Из-за… способности… начинающий программист не может...

    Ок.

    Психологи давно заметили такую особенность у мальчиков и пришли к выводу, что мальчики дошкольного возраста и в начальных классах практически не усваивают то, что им говорят.

    Ссылку на исследование в студию.
    Мужская психология в программировании
  • 0
    И да, я не совсем верно понял задание. :-) Мое решение вернет первый символ, сразу перед которым нет такого же символа, и сразу после которого нет такого же символа, например для 'aabbccaf' вернет 'a'. Но задание сформулировано не очень четко.
    Я хочу работать в Google! Телефонное интервью (часть 3, питоноводческая)
  • 0
    По поводу первого не повторяющегося символа. Не уверен, что самое быстрое решение, но зато короткое и элегантное.

    from itertools import groupby
    
    def non_repeating(line):
        for k, g in groupby(line):
            g_list = list(g)
            if len(g_list) == 1:
                return g_list[0]
        return None
    
    Я хочу работать в Google! Телефонное интервью (часть 3, питоноводческая)
  • 0
    А вообще, если вы так гонитесь за скоростью, перепишите первый вариант на sed, по скорости это решение порвет 99% других (на любом языке), а по соотношению (скорость) / (скорость разработки) — так и все 100%.
    Обычная (или не совсем обычная) транслитерация на Python
  • +2
    Если вам нужно заменить символы одного алфавита на соответствующие им символы другого алфавита. можно обойтись и без циклов, и без регулярок. Есть же string.translate и его верный друг string.maketrans.

    Для замен, в которых участвую строки длиннее одного символа все-так понадобится цикл. Но таких замен сильно меньше односимвольных.
    Обычная (или не совсем обычная) транслитерация на Python
  • +4
    1. Пароль действительно нельзя сообщить быстро, именно поэтому его очень тяжело запомнить. Придумать длинный словесный пароль элементарно: «ехали1медведи2на3велосипеде», я свой шестизначный символьный пароль я забыл через пару секунд.
    2. Ввести пароль с клавиатуры и нажать Enter — секундное дело. Тут же вы заставите пользователя разгадывать капчу. Ладно еще при регистрации это неизбежное (?) зло, но при каждом логине!
    3. Пароль элементарно подсматривается из-за спины.
    Пиктографический пароль. Эксперимент
  • 0
    По поводу 2, тут, скорее, дело вкуса (поэтому «лучше», а не «нужно» :-)), но во view этому коду точно не место. Можно в менеджер, можно в отдельный сериализатор. Даже если его предполагается использовать один раз, есть и другие причины. Например, чтобы протестировать, как работает сериализация, вам нужно «прогнать» view полностью, с контекстом, реквестом и прочим. Если вынести его куда-нибудь, тестирование становится приятным. Документировать код проще, глядя на менеджер, я сразу вижу, что он сериализуется в json, тут логика не так ясна. Сильное связывание опять же, получается, что я не могу сериализовать объект без атрибута name.

    Плюс менеджеры не менее «реюзабельны», чем CBV, тот самый межпроектный DRY.

    > Мне нравится идея выделения отдельной части представления, ответственной за конечное преобразование данных в ответ.
    В вашем случае это HttpResponse(data, content_type='application/json'). Если очень необходимо это выделить, то почему бы не так?
    Class-based views — зачем и как использовать
  • +2
    Примерно так:

    from django.core import serializers
    
    class MyModelManager(models.Manager):
        def to_json(self):
            return serializers.serialize('json', self.all(), fields=('name',), ensure_ascii=False)
    
    class MyModel(models.Model):
        # всякие поля тут
        # ...
        objects = MyModelManager()
    

    Ну и затем вызывать MyModel.objects.to_json().
    Class-based views — зачем и как использовать
  • 0
    В статье речь не о генериках, а о CBV в целом. У базового класса View этого метода нет.
    Class-based views — зачем и как использовать
  • 0
    Это если у класса родителя есть такой метод, и он действительно возвращает dict-like объект. В данном случае это не так.

    Но это хорошо показывает сложность поддержки CBV.
    Class-based views — зачем и как использовать