@Sweet_Sempai будет жить. Поприветствуем!

А, и ещё Comparison with pytest/любым популярным фреймворком.

оно из себя исторгает pytest

README-файлу не хватает структуры. Разбей его на заголовки (рекомендую Installation, Usage, How it works (если ты прям хочешь в детали пуститься, но вообще на мой вкус там слишком много кода для README) и License).

спасибо

А ещё 0.0.3, 0.0.4 — крайне плохие названия коммитов. Используй для этого теги.

+1, коммит должен описывать изменения содержащиеся в коммите.

тестов нет, entry_points для sloth_xml_converter в setuptools нет, дальше не читал..

честно признайся что английский не осилил =)

оно из себя исторгает pytest

Ну короч нужно сравнение, как бы я решал те же задачи без твоей библиотеки и с твоей библиотекой.

А зачем в корне __init__.py? ?

ну для меня это запчасть другого проекта

ну для меня это запчасть другого проекта

Эммм, ну ты неправ

Так не надо делать

+1, коммит должен описывать изменения содержащиеся в коммите.

это да

честно признайся что английский не осилил =)

это почему-же он неосилил английский?

В другом проекте воспользуйся virtualenv и установи туда

может кто-то ниасилил setuptools?

это почему-же он неосилил английский?

это он потому что по жизни вредный

В другом проекте воспользуйся virtualenv и установи туда

ну или вендоринг сделать можно, если так хочется таскать как часть проекта.

Так не надо делать

эээ... а почему?

@densmart будет жить. Поприветствуем!

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

эээ... а почему?

Ну следов твоего другого проекта не должно быть в изолированной библиотеке, это раз. Два — это ж как ты его в другом проекте используешь? Почему не через virtualenv?

есть же неймспейсы.

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

Тоже хотел сказать про названия файлов. Но в классы, мне кажется, норм.

Это ж не го.

ну у меня большой проект. это его запчасть. просто может работать как standalone

Тоже хотел сказать про названия файлов. Но в классы, мне кажется, норм.

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

потому мне так проще с неймингом

и инитом

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

ну у меня большой проект. это его запчасть. просто может работать как standalone

Дело твоё, конечно, но при таком подходе рано или поздно или ты, или пользователи твоей библиотеки будут страдать.

буду иметь ввиду. допилю

неожиданные для меня нюансы

ну у меня большой проект. это его запчасть. просто может работать как standalone

В пипе есть нормальные механизмы для такого кейса.

я в паблик редко что выкладываю

всем привет еще раз. может будут идеи?

как забрать out_features? похоже что это как раз те данные, что мне нужны (14 классов)

print(что?)

Тоже хотел сказать про названия файлов. Но в классы, мне кажется, норм.

по поводу именования вот отличный пример slothtest.sloth_log.setup_sloth_logger или же slothtest.log.setup_logger что лучше?

имхо первый

=)

имхо первый

тяжелое наследие Си?

по поводу именования вот отличный пример slothtest.sloth_log.setup_sloth_logger или же slothtest.log.setup_logger что лучше?

slothtest.log лучше всегда, а конкретная функция — смотря как я буду использовать. Если я напишу from slothtest.log import setup_sloth_logger , код ниже, который её наконец вызовет, будет читаемее с первым вариантом названия.

slothtest.log лучше всегда, а конкретная функция — смотря как я буду использовать. Если я напишу from slothtest.log import setup_sloth_logger , код ниже, который её наконец вызовет, будет читаемее с первым вариантом названия.

да, но это не джава, у тебя есть механизм алиасов.

да, но это не джава, у тебя есть механизм алиасов.

Это аргумент, да.

если ты хочешь добавить дополнительный контекст к имени, которое используешь - ты можешь сделать from slothtest.log import setup_logger as setup_sloth_logger или что имхо более практично from slothtest import log as sloth_log sloth_log.setup_logger()

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

Настроить логирование и открыть лог-файл?

настроить логгирование

странно что у тебя лог не идет сюда же, ты его может явно перенаправил?

gunicorn вроде прячет

да и если у тебя worker вывалился по таймауту то не факт что у тебя там будет эксепшн

gunicorn вроде прячет

на вскидку не помню, вроде бы не должен.

ну т.е. он задает уровень логгирования корневому логгеру через аргументы командной строки

если там исключение - оно должно бы провалиться в лог

однако, если воркер вывалился по таймауту - скорее всего проблема не в исключении.

GeForze Gisha будет жить. Поприветствуем!

Народ, как вставить бинарную переменную (pickle), в varbinary mssql.

При всех попытках использовать pyodbc выходит ОШИБКА HY0000

@doxadoxa будет жить. Поприветствуем!

Народ, как вставить бинарную переменную (pickle), в varbinary mssql.

лучше так не делать.

вообще нехрен пикл пересылать куда-либо за пределы дерева процессов.

https://stackoverflow.com/questions/52458374/insert-pickle-object-to-database-using-pyodbc

Я пытался что то такое сделать

Перекодируй в base 64

И лей

Народ, как вставить бинарную переменную (pickle), в varbinary mssql.

Не надо юзать пикл

Вот прям вообще не надо

Пиклофобы

Пиклофобы

Пиклофилофобы

Пиклофобы

ты ведь понимаешь почему или лишь бы поумничать?

Зависит от кейса

Kirill Serz будет жить. Поприветствуем!

Вот прям вообще не надо

Его не надо использовать там, где передаешьили получаешь данные извне. Вот не надо. Там совсем не надо. Небезопасно это. А локально может и пригодится. Иначе бы выпилили бы давно

Его не надо использовать там, где передаешьили получаешь данные извне. Вот не надо. Там совсем не надо. Небезопасно это. А локально может и пригодится. Иначе бы выпилили бы давно

в базу данных - это уже не локально небезопасно - раз непереносимо - два.

Его не надо использовать там, где передаешьили получаешь данные извне. Вот не надо. Там совсем не надо. Небезопасно это. А локально может и пригодится. Иначе бы выпилили бы давно

База это не локально. Это передача уже

в базу данных - это уже не локально небезопасно - раз непереносимо - два.

я же говорю локально. База не локально

я же говорю локально. База не локально

о чем и речь выше.

Если без трединга и простое что-то - почему бы и нет?

Его не надо использовать там, где передаешьили получаешь данные извне. Вот не надо. Там совсем не надо. Небезопасно это. А локально может и пригодится. Иначе бы выпилили бы давно

Ну он как минимум юзается multiprocessing, поэтому нельзя удалять

Если без трединга и простое что-то - почему бы и нет?

при чем тут /мат/ трединг?

А что такое? Только религиозное "не надо"?

Зависит от кейса

Конечно зависит. 99% не знают этих кейсов

Ну не юзай

А что такое? Только религиозное "не надо"?

Павел перестаньте нести чушь и пройдите в букварь

Если без трединга и простое что-то - почему бы и нет?

Дело же не в потоках. А в возможности запиклить кем-нибудь какое-нибудь Г , а твой код распиклит и ОПА, неудобняк.

Дело же не в потоках. А в возможности запиклить кем-нибудь какое-нибудь Г , а твой код распиклит и ОПА, неудобняк.

Это все решаемо

Зависит от кейсов

Еще раз для остолопов. Pickle - небезопасен, непереносим.