На 2.7 уже можно использовать .format во все поля. Еще from future import unicode_literals обмазаться и жить можно

"Угрожали", что могут убрать в будующем.

Так и не убирали.

пообещали начать убирать, но поднялся вой и оставили.

Там куча и % форматирования

ага, и что теперь делать?

ага, и что теперь делать?

головой думать, что в какой ситуации удобнее.

чего-то этот спор мне уже начинает казаться совершенно пустым

пообещали начать убирать, но поднялся вой и оставили.

В любом случае, не меняет того факта, что признали устаревшим. То, что собирались убирать - что-то да значит.

чего-то этот спор мне уже начинает казаться совершенно пустым

Так и есть. Интересно просто мнение других узнать. :)

ага, и что теперь делать?

Наверное не говорить мне что их использовать нет смысла) Пока они быстрее и пока они работают лично я буду их использовать. Когда перейду на 3.6 повсместно то f-string Но .format врядли

Наверное не говорить мне что их использовать нет смысла) Пока они быстрее и пока они работают лично я буду их использовать. Когда перейду на 3.6 повсместно то f-string Но .format врядли

А кто вам говорил что их использовать смысла нет?

Обожаю такое :)

А кто вам говорил что их использовать смысла нет?

Говорили

А кто вам говорил что их использовать смысла нет?

Я писал, что *Я* не вижу смысла их использовать

до 3.6 запись log_name = '/var/log/%s.log' % project была удобнее, чем через формат.

Я писал, что *Я* не вижу смысла их использовать

А я вижу, как минимум потому что они быстре

до 3.6 запись log_name = '/var/log/%s.log' % project была удобнее, чем через формат.

после 3.6 - лучше конечно f''

до 3.6 запись log_name = '/var/log/%s.log' % project была удобнее, чем через формат.

Да мне тоже нравится такая запись больше чем вские .format

после 3.6 - лучше конечно f''

с моей точки зрения

Да мне тоже нравится такая запись больше чем вские .format

но если в строке нескольо переменных, то мне станвоится страшно промахнуться.

f-string еще не скоро станет стандартом, в питон все очень медленно и еще годами будут проекты работать на 2.7

особенно если одна переменная должна несколько раз участвовать в формате

так в формате так же неименновынные переменные указываются только вместо %s используют {}.там так же легко промазать.

так в формате так же неименновынные переменные указываются только вместо %s используют {}.там так же легко промазать.

>>> '{name} {name}'.format(name='abc') 'abc abc'

>>> '{name} {name}'.format(name='abc') 'abc abc'

>>> '%(name)s %(name)s' % {'name':'abc'} 'abc abc'

К чему это?

К чему это?

к необязательности использовать безымянных {}

И там и там необязательно

Но когда их много и там и там будут проблемы

1.11, считайте, уже вышла, есть релиз-кандидат, 1.11 финальная версия выйдет ориентировочно 4-5 апреля, но можно и не ждать, релиз-кандидаты у Django всегда стабильные... по крайней мере, у меня с ними никаких проблем не было никогда... версия 2.0, которая выйдет в декабре, не будет поддерживать Python 2.7

Пора уже давно хоронить py2 в целом

Да пора уже и fortran и cobol хоронить, а есть системы которые на них работают

Новые проекты на 2.7 точно не стоит начинать, это да

Ну я до сих пор некоторые маленькие проекты на 2.7 делаю

Привычка?

Я вот на 2.7 делаю только если нужна либа которую ебанешься портировать на 3+

Ну всякие там парсеры консольные и прочую лабуду)

Это скорее крошечные, чем мелкие xD

Пока в линкусе по умолчанию команда python выполняет 2.7 приходится на нем делать

Пока в линкусе по умолчанию команда python выполняет 2.7 приходится на нем делать

Линукс разный бывает. У меня 3.6

Обычный коробочный ubuntu

а в чем проблема поставить рядом другую версию?

Я сделал python3.6 дефолтным тоже

Но это конечно только на машинах которыми кроме меня никто не пользуется

а в чем проблема поставить рядом другую версию?

3.5 по тоже из коробки уже стоит в убунте

Десяток серверов везде 2.7 по умолчанию и даже те что новые все равно по умолчанию 2.7, то что уже работает оно работает с 2.7, делая на 3.6 слишком долго раъъяснений нужно, проще на 2.7 продолжать

Да но выполняют python бла-бла, а там 2.7 по умолчанию

Даже в новой версии

Десяток серверов везде 2.7 по умолчанию и даже те что новые все равно по умолчанию 2.7, то что уже работает оно работает с 2.7, делая на 3.6 слишком долго раъъяснений нужно, проще на 2.7 продолжать

А деплоишь чтоли не в virtualenv?

А деплоишь чтоли не в virtualenv?

Там все сложно) Как это обчно бывает когда много всего, зоопарк, много разработчиков и проекты не новые

убунта 16.4 дефолтный 3.5

ааааааааааааааа не нихера

сорян

ни хера)

2.7 везде до сих пор

таки да

а я чет был уверен что 3.5 на убунте

хз почему

Ну я не спец в этом, но мне кажется это из-за системы Apt, которая на питоне

там из коробки стоит и 2.7 и 3.5

Ну и куча других утилит

2.7 везде до сих пор

На арче вроде уже во всю 3.5

там из коробки стоит и 2.7 и 3.5

Стоит да, но что по умолчанию указано, это другое, а по умолчанию интерпретатор питона 2.7

привет! добавь, плиз, в FAQ ссылку на dpaste.de с краткой инструкцией, зачем оно нужно

ага, добавлю ?

у меня pyenv'ом выставлен 3.6 по дефолту, соответственно все проекты на 3.6 делаю)

2.7 везде до сих пор

Под арчем дефолт 3.6

Я не так выразился, везде всмысле у на, а у нас ток Убунта, а арчу везет что я могу сказатЬ)

В Убунту даже пакета нет для 3.6, только в 16.10, а на серверах LTS онли

Гайс, какие принципиальные различия у тестовой бд на sqlite и postgresql. После перехода, похерилось наверно почти 50% тестов. Первая мысль это, то что id у объектов задается совсем иначе, но наверное это не единственное различие. И есть еще вопрос, есть ли хоть какой-то адекватный способ переписать тесты с sqlite на postgresql т.к. первое, что приходит на ум, это просто взять и с нуля все переписать.

ERROR: S client not available

Эм о.О

> тесты > sqlite што

а большой проект?

Для тестов используй фикстуры хотя бы. Ну или factory boy

Небольшой

Покажи тесты хоть

я через по большей части через setup все делал

https://github.com/YraganTron/Imageboard/tree/master/imageboard/tests

наверное имеет смысл в test_views смотреть

Кто-то писал, что может помочь с pycharm?)

Кто-то писал, что может помочь с pycharm?)

А что с ним не так?

Видимо хочет ключик)

тут кто-то хвастался своим сервером авторизации

он же писал что для себя держит

Именно)

Видимо хочет ключик)

всем привет

кто-нибудь знает как сделать более user-friendly поле HStoreField в админке?

Обновился до последней версии Pycharm теперь долго грузиться ...

кто-нибудь знает как сделать более user-friendly поле HStoreField в админке?

https://github.com/djangonauts/django-hstore/blob/master/django_hstore/static/admin/js/django_hstore/hstore-widget.js

я нативное поле имею ввиду

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

Где вы выстраиваете связи между моделями? У себя в голове и сразу реализуете или как-то графически? :)

draw.io часто юзаю для этого

В работе с базами данных полный новичок, сложно ориентироваться. Хотелось бы видеть перед глазами все эти связи.

draw.io часто юзаю для этого

Хороший инструмент, но он слишком всенаправленный, что-ли :D Не очень удобно.

главное в нем разобраться, а дальше изи

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

в django-hstore виджет автоматически выводится или его нужно как-то отдельно включать?

Автоматом же, через jquery вроде через IDшник цепляется

Кто тут мог бы себе взять Джуна в подчинение?

За идею

В рабство)