Господа, поделитесь пожалуйста, что сейчас модно советовать почитать по Python для углубленного понимания?

Что такое "углубленное понимание" Python'a?

Ну чтобы про вещи типа метаклассов, дескрипторов, gc, наследования и тд было бы поподробнее описано.

Ну чтобы про вещи типа метаклассов, дескрипторов, gc, наследования и тд было бы поподробнее описано.

"Python. К вершинам мастерства" Лучано Рамальо. В этой книге будет все описанное кроме gc.

GC шепедева читай и gc handbook - только это не про питон

Есть еще книга про gc: The Garbage Collection Handbook The Art of Automatic Memory Management

Самое обидное, что эти книги не помогают выпускать качественный продукт в срок :D

?

Самое обидное, что эти книги не помогают выпускать качественный продукт в срок :D

Ничто не помогает...

Ничто не помогает...

Помогает кое что . ...

Ну чтобы про вещи типа метаклассов, дескрипторов, gc, наследования и тд было бы поподробнее описано.

А что там описывать в gc с подсчётом ссылок?

А что там описывать в gc с подсчётом ссылок?

Ну gc это не только подсчет ссылок

Ну gc это не только подсчет ссылок

а что еще?

а что еще?

Строго говоря подсчет ссылок это воообще не gc. Когда я написал что в книге должна быть инфа по gc имелось ввиду, что должна быть информация по управлению памятью впринципе.

Строго говоря подсчет ссылок это воообще не gc. Когда я написал что в книге должна быть инфа по gc имелось ввиду, что должна быть информация по управлению памятью впринципе.

Ну вот да. Но в cpython только подсчет ссылок.

Что значит подсчет ссылок? Incref/decref?

Ну вот да. Но в cpython только подсчет ссылок.

Ну нет же, не только подсчет

+

Ну нет же, не только подсчет

А что ещё?

Подсчет ссылок не спасет при циклических ссылках. Так что есть и поколения

Подсчет ссылок не спасет при циклических ссылках. Так что есть и поколения

А, внезапно да.

The Garbage Collection Handbook — хорошая книжка, библиография на 130 страниц

а как вы своём коде делаете красивые log messages?

а как вы своём коде делаете красивые log messages?

def log: printf ?

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

Было бы ещё хорошо научиться читать описание групп. У меня пока интернет шальной можете исправить ) минут через 5 исправлю сам

а как вы своём коде делаете красивые log messages?

Рома, есть такой пакет logging. Мало кто умеет, но многие используют. Так вот, там есть форматтеры и тонкая настройка от кого и какой уровень каким форматтером куда писать. У меня всё;)

Было бы ещё хорошо научиться читать описание групп. У меня пока интернет шальной можете исправить ) минут через 5 исправлю сам

Прошло больше пяти минут:) Я забанил.

Рома, есть такой пакет logging. Мало кто умеет, но многие используют. Так вот, там есть форматтеры и тонкая настройка от кого и какой уровень каким форматтером куда писать. У меня всё;)

Я про то как в коде у тебя выглядят сообщения с параметрами, вроде "Job {job_id} terminated by user {username} with reason '{reason}"

Тут хорошо зашли бы f-strings

Я про то как в коде у тебя выглядят сообщения с параметрами, вроде "Job {job_id} terminated by user {username} with reason '{reason}"

Последнее время f-строки в log.LEVEL

Последнее время f-строки в log.LEVEL

Но я очень не хочу f-strings ;)

log = logging.get_logger(__name__) В начале модуля

Но я очень не хочу f-strings ;)

Ты уж определись

Но я очень не хочу f-strings ;)

По большому счету по фигу. Твое дело отдать сообщение. Как ты это сделаешь - подробности реализации

По большому счету по фигу. Твое дело отдать сообщение. Как ты это сделаешь - подробности реализации

Человек про то, что ему не нравится как выглядит код с логгированием. Я так понял.

Человек про то, что ему не нравится как выглядит код с логгированием. Я так понял.

Да, все верно.

Прошло больше пяти минут:) Я забанил.

Спасибо , а то у меня Интернет по расписанию и не всегда ожидаемому ))

Но я очень не хочу f-strings ;)

Ну можно по классике logger.debug("Job %s terminated by user %s with reason %s", job_id, username, reason)

Ну можно по классике logger.debug("Job %s terminated by user %s with reason %s", job_id, username, reason)

И это единственно верный способ писать в лог, если используется модуль logging.

Мне не понятно только, почему до сих пор модуль logging не поддерживает форматирование в стиле format через {}. logger.info('hello {name}', name=petya)

Чот я не въехал, а зощем, если есть format?

Чот я не въехал, а зощем, если есть format?

100500 раз об этом уже говорили, мне лень объяснять... может кто-нибудь другой расскажет

Если кратко, то во-первых, дополнительный оверхед на форматирование, даже если сообщения с этого уровня логгирования фильтруются (не выводятся), во-вторых, всякие тулы, которые собирают логи, начинают тупить.

Разумно, спасибо. Тогда возможно синтаксиса с {} нет потому что обратная совместимость, где-то могут быть строки с {}, которые не предполагается заменять на аргумент. Хотя, думаю, это не большая проблема.

Скорее всего да, есть подводные камни обратной совместимости. Видимо, чтобы ничего не сломать оставили архаичный синтаксис форматирования. Работает — не трогай. :)

The style parameter can be one of ‘%’, ‘{‘ or ‘$’ and determines how the format string will be merged with its data: using one of %-formatting, str.format() or string.Template. See Using particular formatting styles throughout your application for more information on using {- and $-formatting for log messages. Changed in version 3.2: The style parameter was added.

Как нет, если есть

ERROR: S client not available

Это параметр конструктора formatter

Это не про то

Это про параметризацию форматтера, а не про форматирование сообщений

Разве? Я так понимаю если сделать style='{', то форматтер будет обрабатывать лог мессаджи через str.format

Попробуй :) Это вот про это FORMAT = '%(asctime)-15s %(clientip)s %(user)-8s %(message)s' logging.basicConfig(format=FORMAT) FORMAT = '{asctime} {clientip} {user} {message}' logging.basicConfig(format=FORMAT)

А мы разве не про это говорим?

А, подожди

Я думал это и на то, и на другое влияет

К сожалению, не влияет на форматирование сообщений

Я тоже был удивлён

Печаль

Печаль

Ага. Ну то есть если ты задашь форматтер как-то так: f = logging.Formatter('%(asctime)-15s %(clientip)s %(user)-8s %(message)s', style='{') То твой логгер перестанет подставлять параметры. и В любом случае будет ругаться на {} в строке сообщения. logger.error('hello') ERROR:root:hello %(asctime)-15s %(clientip)s %(user)-8s %(message)s logger.error('hello {}', 45) --- Logging error --- Message: 'hello {}' Arguments: (45,) Очень затейливо они сделали, конечно. Казалось бы, кому надо {} в строке формата? Там то как раз можно обойтись единым синтаксисом.

Ага. Ну то есть если ты задашь форматтер как-то так: f = logging.Formatter('%(asctime)-15s %(clientip)s %(user)-8s %(message)s', style='{') То твой логгер перестанет подставлять параметры. и В любом случае будет ругаться на {} в строке сообщения. logger.error('hello') ERROR:root:hello %(asctime)-15s %(clientip)s %(user)-8s %(message)s logger.error('hello {}', 45) --- Logging error --- Message: 'hello {}' Arguments: (45,) Очень затейливо они сделали, конечно. Казалось бы, кому надо {} в строке формата? Там то как раз можно обойтись единым синтаксисом.

Имхо f-строки достаточно быстрые, чтобы не париться за фильтрацию лишних логов

Имхо f-строки достаточно быстрые, чтобы не париться за фильтрацию лишних логов

По крайней мере, пока это не станет узким местом

Имхо f-строки достаточно быстрые, чтобы не париться за фильтрацию лишних логов

Может я там вывожу кастомный класс, в котором метод __str__ работает 10 секунд ?

Может я там вывожу кастомный класс, в котором метод __str__ работает 10 секунд ?

И тебе ещё тут не оторвали? Нереальная ситуация:)

Может я там вывожу кастомный класс, в котором метод __str__ работает 10 секунд ?

Ну и это подпадает под определение "стало узким местом"

И тебе ещё тут не оторвали? Нереальная ситуация:)

Я такое не писал, но видел. Там было, конечно, не 10 секунд, но секунду точно. Адово, конечно, но всякое бывает. :)

Мне ещё в logging не хватает управления логами на уровне контекста, ну, например, как-то так: with logging.level(logging.WARNING): requests.post(url, data=data) или with logging.level('urllib3', logging.WARNING): requests.post(url, data=data) Это если я не хочу, скажем, видеть debug-логов из urllib3 при вызове requests.post, а в остальных случаях хочу.

Мне ещё в logging не хватает управления логами на уровне контекста, ну, например, как-то так: with logging.level(logging.WARNING): requests.post(url, data=data) или with logging.level('urllib3', logging.WARNING): requests.post(url, data=data) Это если я не хочу, скажем, видеть debug-логов из urllib3 при вызове requests.post, а в остальных случаях хочу.

Там была какая-то тонкая настройка по источникам, можно настраивать уровень логирования, филтры, направления и т. п.

Там была какая-то тонкая настройка по источникам, можно настраивать уровень логирования, филтры, направления и т. п.

Да, там можно целый конфиг написать, но я сейчас просто в таком случае делаю так: logging.getLogger("urllib3").setLevel(logging.WARNING) А хотелось бы как с warnings: with warnings.catch_warnings(): warnings.simplefilter("ignore") requests.post(url, data=data, verify=False)

Да, там можно целый конфиг написать, но я сейчас просто в таком случае делаю так: logging.getLogger("urllib3").setLevel(logging.WARNING) А хотелось бы как с warnings: with warnings.catch_warnings(): warnings.simplefilter("ignore") requests.post(url, data=data, verify=False)

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

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

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