А экономия места не приведет к проблемам?)

Скорее просядет производительность, поскольку эта функция вызывается чуть более чем часто.

Стоит ещё учитывать, что python ещё и про скрипты

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

* хотя нет, не лень, увы, дедлайны *

Если основное время - это работа с бд, чем помогут си? А если нет, то точно питон, а не завтыки?

Если основное время - это работа с бд, чем помогут си? А если нет, то точно питон, а не завтыки?

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

ты больше просядешь в базе, от языка тут мало зависит

ты больше просядешь в базе, от языка тут мало зависит

Да, я знаю, я на это уже указал. Да и собственно, речь даже была не об этом, а о кол-ве строк 1200 :) Хотя там одни сплошные if и проверки раздельных запросов.

лучше не трогать

но за такое надо бить по рукам, а сейчас уже поздно

😁 Ну я вот и думаю, как можно сократить 1200 строк? Разбить на подфункции? В принципе можно. Но там формируется достаточно большой контекст (аккумулируется структура данных, каждая часть которой необходима для следующих запросов).

есть старый принцип, работает - не трогай!!

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

есть старый принцип, работает - не трогай!!

Таким принципом руководствовались когда создавали кучу бд на разных серверах под разные направления статистики 😂 пришлось продолжить их идею (примерно так же ответили когда зашла речь о кликхаусе)

pep8 + pylint все расскажут и покажут

Про pep8 знаю, а вот про pylint нет. Сябки

Про pep8 знаю, а вот про pylint нет. Сябки

Стоит заметить, что у него в целом есть конкуренты, например, pyflakes. Выбирай, что больше будет нравится)

Да, я знаю, я на это уже указал. Да и собственно, речь даже была не об этом, а о кол-ве строк 1200 :) Хотя там одни сплошные if и проверки раздельных запросов.

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

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

Да, однозначно следует пересмотреть в корне все. Но у серверов БД есть две стороны, одна в эти самые БД пишет, другая с них читает. И помимо БД деньги были уплОчены и за пишущие стороны. Поэтому позиция заказчика вполне оправдана - мы уже отбили затраты и хочется насладить прибылью. Поэтому, интересы Итшников для них находятся не в приоритете пирамиды :) А по разбивке на мелкие функции - стала бы обрисованная, пусть и не полным образом, задача отмазкой на вопрос - "куда нна столько строк в функции на питоне?".

Или PEP и всё тут!?

Я, кстати, не вижу в pep 8 упоминания количества строк

Я, кстати, не вижу в pep 8 упоминания количества строк

На эту ситуацию уругается pylint. Хотя да, о кол-ве нет упоминания (только что пробежался).

В pylint там есть по умолчанию ограничение на 100 строк, но его всегда можно отключить для конкретной функции

С комментом почему так сделано.

Есть только длина строки

А, ну да, там есть max-module-lines=1000

Думаю, данный вопрос в любом случае скорее религиозный, поскольку с ихсодниками вряд ли кто-то будет дальше работать. А так, между нами говоря, я там еще и строки до 200 символов в ряд увеличил (иначе 1200 строк превратились бы в нечто большее) 😂

У меня стоит ограничение на 400, я просто следую правилу, что бы все умещалось в один экран

Экраны то уже большие стали

Да, 80 символов - это для консолек уже как-то. А 400 в ширину (или это о макс. кол-ве строк?)?

в ширину

☺ мне прям полегчало, часто встречаю противников моих 200

Вопрос по поводу переноса длинных строк. Верно ли, или нет?

Вопрос по поводу переноса длинных строк. Верно ли, или нет?

ктото бота пилит)

ктото бота пилит)

Уже напилен, дважды, второй раз с классами, сейчас привожу кодец в порядок, чтобы на гитлаб репу залить, чтобы не потерять)

Вопрос по поводу переноса длинных строк. Верно ли, или нет?

я не претендую на истину в последней инстанции но имхо надо переносить строки после ...photo( chat_id.... caption... photo...

а т.к. я за хаос, то перенос строк не для меня, путь будет каша)

Так?

Или равнять параметры по скобочке открывающей?

между параметром и "=" пробел и между "=" и выражениями пробел

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

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

Ну как нет, вроде в pep8 сказано об этом. Хотя я хз, может быть не тот pep8 смотрю

Угусь. Так и есть. Наверное, я даже согласен с ними в этом моменте)

Угусь. Так и есть. Наверное, я даже согласен с ними в этом моменте)

ого, спасибо, а я думал наоборот

ого, спасибо, а я думал наоборот

Вот, кстати, как в гугле осуществляют документирование

Мне это нравится

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

keywords arguments

"для обозначение аргумента-ключа или значения по умолчанию"

Что, похоже, не одно и тоже

Но я могу ошибаться)

Вот, кстати, как в гугле осуществляют документирование

Вот только sphinx в такие штуки не умеет. Потому лучше так делать: https://thomas-cokelaer.info/tutorials/sphinx/docstring_python.html

:param arg1: description :param arg2: description :type arg1: type description :type arg1: type description :return: return description :rtype: the return type description

Хотя может где-то и лежит плагин для этого

Интересненько... надо и это попробовать

Хотя может где-то и лежит плагин для этого

Всё отлично, спинфикс тянет гугловский стиль

Окей, значит мой косяк(

Ну, то, мне скинули - слишком перегруженным кажется, во всяком случае пока. У меня сейчас и так получается 17 строк доков и 1 строка кода :D

всем привет! подскажите, пожалуйста, как можно замокировать итерируемый объект, чтобы при проходе с помощью for .. in получать требуемые значения? мокирование __getitem__ и __len__ не дало желаемого результата, к сожалению

всем привет! подскажите, пожалуйста, как можно замокировать итерируемый объект, чтобы при проходе с помощью for .. in получать требуемые значения? мокирование __getitem__ и __len__ не дало желаемого результата, к сожалению

Попробуйте http://programmaticallyspeaking.com/mocking-__iter__-with-a-magic-mock-in-python.html

Мда, только так)

взлетело, спасибо! с MagicMock так не получалось)

Очень сложно с 80 символами, увеличил до 100)

Я бы сразу до 200 увеличил

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

А само количество не очень важно, как мне кажется

Ну, у меня дома нормальный фуллхд моник, а на работе 1366 который, а часто надо два файлика в рабочей области держать

Тогда, конечно, без вариантов)

`lst = list(range(i))`

Для pop(0) это получается O(n)? Для pop() это O(1)?

да

Вопрос по поводу переноса длинных строк. Верно ли, или нет?

Отформатиру пичармом

И перед чат айди равно поставь ентер

Что за фигня - не получается импортировать модель, которая лежит в папке ~/api/models/models.py(модель - это класс Users). Импортирую в файл ~/api/core/backup.py

python3.6 backup.py Traceback (most recent call last): File "backup.py", line 2, in <module> from models.models import Users ModuleNotFoundError: No module named 'models'

__init__.py есть?

Да, есть

Самое забавное - если запускать через gunicorn, всё заработает.

Из api запускаешь?