В том треде репозитория black накидали очень много хороших аргументов, почему будет лучше, когда стиль кавычек можно выбрать самому. Хорошо, что мейнтейнер хотя бы добавил skip-string-normalization, а вообще мне показалось, что он отклонил запрос исходя из собственных субъективных предпочтений.
Когда мы у себя внедряли black, я тоже рассматривал вариант с форком (но это сразу показалось сложно и лениво), поэтому в итоге пришли к варианту c pre-commit: т.е. в начале в .pre-commit-config.yaml указан black, потом isort, а потом double-quote-string-fixer (встроенный в pre-commit хук). Works like a charm.
Спасибо. Явно указывать, что сохранять, все равно, конечно, надо, но в legacy коде хотя бы можно не рыться в надежде что-то таким образом оптимизировать :)
А HOT будет применен, если обновится поле с индексом, но значение останется тем же? По ссылке про него прочитал, но не совсем понятно, "обновление поля" — это любой апдейт или именно изменение значения.
Спасибо за статьи, довольно доступная подача не самого простого материала. Хорошо помогает упорядочить свои отрывочные знания.
Уточните, пожалуйста, следующий момент. Вот цитата: "Команда UPDATE сама выбирает минимальный подходящий режим блокировки; обычно строки блокируются в режиме FOR NO KEY UPDATE".
Плюс к этому известно, что любой апдейт в постгресе все равно действует как delete+insert, даже если обновляется одно "простое" поле. Во многих ORM удобно использовать save метод, который генерирует update на все поля, и изменившиеся, и нет. Постгрес достаточно умный, чтобы понять, что KEY поля не менялись, или нет? И вообще практика при апдейте указывать только нужные поля реально несёт какую-то пользу (ну кроме сокращения трафика).
Я, например, уже привык этот дайджест открывать заранее в новом окне и накликивать в новые вкладки всё, что более-менее интересно. А иначе перебор получается вместе с тем, что обычно открыто. А сегодня действительно обошлось без этого )
Спасибо, отличные новости. Пользуясь случаем, хотелось бы узнать, есть ли какие-нибудь оценки по времени на 4 версию? Поискал у вас на сайте, но даже пока никаких упоминаний нет.
Здравствуйте. Заинтересовало пост-автодополнение для JavaScript. Будет ли оно доступно в PyCharm?
Ведь, насколько я понимаю, у PyCharm и WebStorm общая кодовая база, соответственно в новом релизе все описанное выше должно тоже стать доступным.
Ну по поводу "\" несколько спорно.
Часто это удобней, чем вставлять скобки (например, этих скобок там уже и так много).
В том же Django в исходниках видел много раз.
Только вот теперь константы
DATABASE_ENGINE = ''
DATABASE_NAME = ''
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_HOST = ''
DATABASE_PORT = ''
вроде как deprecated.
С png там дело в том, что при анимации (fadeIn, fadeOut) картинки с альфа-каналом там появляется черный фон на месте пикселей с прозрачностью. В некоторых плагинах к jQuery там даже fade убирается, если IE.
А ClearType, например, бесит тем, что при применении к слою (и не только) с текстом каких-то эффектов — то есть по сути filter, т.к. нормально он ничего не поддерживает, ClearType просто отключается.
В 6-ке было незаметно, т.к. она не включала CT по умолчанию, а в 7 и 8 проблема налицо.
Чтобы не ходить далеко за примером — откройте youtube.com через 7 или 8 — и будет видно, что весть текст внутри кнопок идет без CT. А если в код посмотреть, это как раз потому, что там применены фильтры.
В демках как-то ничего полезного почти.
border-radius увидел, а где text-shadow? По поводу png ничего не нашел, честно говоря. Они, похоже, считают, что с png все нормально стало. А вот бесполезный эффект постепенного увеличения размера шрифта почему-то есть.
Вон даже на youtube все на css3 — тени для кнопочек, градиенты и прочее.
И только в ie, даже 8, половина эффектов или не работает или через одно место.
В том треде репозитория black накидали очень много хороших аргументов, почему будет лучше, когда стиль кавычек можно выбрать самому. Хорошо, что мейнтейнер хотя бы добавил
skip-string-normalization, а вообще мне показалось, что он отклонил запрос исходя из собственных субъективных предпочтений.Когда мы у себя внедряли black, я тоже рассматривал вариант с форком (но это сразу показалось сложно и лениво), поэтому в итоге пришли к варианту c pre-commit: т.е. в начале в .pre-commit-config.yaml указан black, потом isort, а потом
double-quote-string-fixer(встроенный в pre-commit хук). Works like a charm.Спасибо. Явно указывать, что сохранять, все равно, конечно, надо, но в legacy коде хотя бы можно не рыться в надежде что-то таким образом оптимизировать :)
А HOT будет применен, если обновится поле с индексом, но значение останется тем же? По ссылке про него прочитал, но не совсем понятно, "обновление поля" — это любой апдейт или именно изменение значения.
Спасибо за статьи, довольно доступная подача не самого простого материала. Хорошо помогает упорядочить свои отрывочные знания.
Уточните, пожалуйста, следующий момент. Вот цитата: "Команда UPDATE сама выбирает минимальный подходящий режим блокировки; обычно строки блокируются в режиме FOR NO KEY UPDATE".
Плюс к этому известно, что любой апдейт в постгресе все равно действует как delete+insert, даже если обновляется одно "простое" поле. Во многих ORM удобно использовать save метод, который генерирует update на все поля, и изменившиеся, и нет. Постгрес достаточно умный, чтобы понять, что KEY поля не менялись, или нет? И вообще практика при апдейте указывать только нужные поля реально несёт какую-то пользу (ну кроме сокращения трафика).
docs.djangoproject.com/en/1.7/topics/db/transactions/#controlling-transactions-explicitly
Ведь, насколько я понимаю, у PyCharm и WebStorm общая кодовая база, соответственно в новом релизе все описанное выше должно тоже стать доступным.
Правда оно у меня выдернуто из джанги и лежит как отдельное приложение, но там единственное изменение — это пара полей добавлено.
Каждый раз раздражает это отсутствие склонений/падежей, но попривык уже, а тут по большому счету даже манкипатчинга удалось избежать.
Спасибо.
Часто это удобней, чем вставлять скобки (например, этих скобок там уже и так много).
В том же Django в исходниках видел много раз.
ну и заодно чтобы json расшифровывался, как в firebug
DATABASE_ENGINE = ''
DATABASE_NAME = ''
DATABASE_USER = ''
DATABASE_PASSWORD = ''
DATABASE_HOST = ''
DATABASE_PORT = ''
вроде как deprecated.
Лучше использовать DATABASES = {
'engine':…
…
}.
Дайте 2!
С png там дело в том, что при анимации (fadeIn, fadeOut) картинки с альфа-каналом там появляется черный фон на месте пикселей с прозрачностью. В некоторых плагинах к jQuery там даже fade убирается, если IE.
А ClearType, например, бесит тем, что при применении к слою (и не только) с текстом каких-то эффектов — то есть по сути filter, т.к. нормально он ничего не поддерживает, ClearType просто отключается.
В 6-ке было незаметно, т.к. она не включала CT по умолчанию, а в 7 и 8 проблема налицо.
Чтобы не ходить далеко за примером — откройте youtube.com через 7 или 8 — и будет видно, что весть текст внутри кнопок идет без CT. А если в код посмотреть, это как раз потому, что там применены фильтры.
border-radius увидел, а где text-shadow? По поводу png ничего не нашел, честно говоря. Они, похоже, считают, что с png все нормально стало. А вот бесполезный эффект постепенного увеличения размера шрифта почему-то есть.
Вон даже на youtube все на css3 — тени для кнопочек, градиенты и прочее.
И только в ie, даже 8, половина эффектов или не работает или через одно место.