У тебя сеть переобучилась

У тебя сеть переобучилась

Согласен. Я пошел короче. Всем орех.

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

Заходят как-то бот, профессионал и гуееб в бар

А бармен им чо?

Пока не ушел, бот - я?

А Бобокало им: "с вас 2 тысячи и наливает авансом"

А они не платят

А бармен им - белорусов не обслуживаем

А бармен им - белорусов не обслуживаем

Щас обидно было

А бармен им - белорусов не обслуживаем

Все из-за прокси:(

https://pymotw.com/3/configparser/index.html

полный фарш

https://pymotw.com/3/configparser/index.html

разобрался, ответил сам же себе в сообщении, спасибо

чатик, подскажи, пожалуйста, будь лапочкой: какие есть хорошие практики создания конфигурационных файлов для больших (на несколько микросервисов) проектов? если есть, то где про них можно прочитать?

Использую подход в виде импорта модуля config. В config/__init__.py переменная, указывающая на актуальный конфиг. В каталоге config несколько файлов-конфигов. Например config/devel.py или config/prod.py

Использую подход в виде импорта модуля config. В config/__init__.py переменная, указывающая на актуальный конфиг. В каталоге config несколько файлов-конфигов. Например config/devel.py или config/prod.py

хорошая идея, я буду тогда папку под конфиги выделять, и configparser'ом проходить, спасибо)

хорошая идея, я буду тогда папку под конфиги выделять, и configparser'ом проходить, спасибо)

Убери configparser. Лишний гемор. Бери сразу переменные из импортированного модуля.

Убери configparser. Лишний гемор. Бери сразу переменные из импортированного модуля.

мне принципиально именно простые файлы конфигурации, что бы никто не мучал мозги. (уж заказчик такой к сожалению)

import config config.DEBUG

import config config.DEBUG

а так можно??? 5 сек, попробую нагуглить

Они и так простые. Что там сложного? DEBUG = True

# Количество выводимых элементов на странице ITEMS_ON_PAGE = 100

Они и так простые. Что там сложного? DEBUG = True

аааа, в этом плане

я понял, тогда так и сделаю, спасибо

я понял, тогда так и сделаю, спасибо

?

а так можно??? 5 сек, попробую нагуглить

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

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

окей, предположим, есть 3 микросервиса, у каждого есть общие и собственные переменные, которые нужно пихать в конфиги. правильней будет распределять конфиги по файлам main.ini,container1.ini,container2.ini и пр. или в один? ибо конфигов там приличное количество, если честно

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

окей, предположим, есть 3 микросервиса, у каждого есть общие и собственные переменные, которые нужно пихать в конфиги. правильней будет распределять конфиги по файлам main.ini,container1.ini,container2.ini и пр. или в один? ибо конфигов там приличное количество, если честно

конфиг поддерживает группы же. У меня было что-то подобное, в моём случае было целесообразно что-то в духе [global] param1... param2... [device1] ... [device2] ... а так это уже от конкретной ситуации зависит

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

Чем якобы правильно, отличается от якобы не нужно, что делает чёрное белым и наоборот?

конфиг поддерживает группы же. У меня было что-то подобное, в моём случае было целесообразно что-то в духе [global] param1... param2... [device1] ... [device2] ... а так это уже от конкретной ситуации зависит

а группа в группе может быть? я почему-то такого нигде не находил, на device1 например, нужно разделение конфигов по работе с бд и работе с форматированием api, к примеру

Чем якобы правильно, отличается от якобы не нужно, что делает чёрное белым и наоборот?

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

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

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

Раз https://docs.djangoproject.com/en/2.0/topics/settings/ Два http://flask.pocoo.org/docs/1.0/config/

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

Так что можешь считать стандартом

Раз https://docs.djangoproject.com/en/2.0/topics/settings/ Два http://flask.pocoo.org/docs/1.0/config/

эге...

эге...

Гибче наследованием, подгруппами и прочими плюшками

Так что можешь считать стандартом

хорошо, тогда просто риторический вопрос, и отстану: в целом в разработке, не только в пайтоне, а вообще, как лучше конфиги писать? ну, т.е. у node'вцев есть правило писать .json, гоферы .yml, питонисты config.py, разве какого-то общего стандарта нет?

хорошо, тогда просто риторический вопрос, и отстану: в целом в разработке, не только в пайтоне, а вообще, как лучше конфиги писать? ну, т.е. у node'вцев есть правило писать .json, гоферы .yml, питонисты config.py, разве какого-то общего стандарта нет?

Нет. Знаешь где форточки свои конфиги держат? Правильно, вообще в реестре, который по сути ФС внутри файла.

Чем якобы правильно, отличается от якобы не нужно, что делает чёрное белым и наоборот?

ну какбэ натягивание совы на глобус и забивание гвоздей микроскопом - изначально порочные практики. Конфиг - это конфиг, сорц - это сорц, нафига смешивать? Формат конфига универсален, читаем человеком независимо от знания конкретного языка и средствами других языков. А если конфиг изменится в процессе работы и его надо будет сохранить - редактировать сорц из-под себя как текстовый файл? Кончайте страдать ненужной фигнёй

Нет. Знаешь где форточки свои конфиги держат? Правильно, вообще в реестре, который по сути ФС внутри файла.

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

Нет. Знаешь где форточки свои конфиги держат? Правильно, вообще в реестре, который по сути ФС внутри файла.

Саша, где-то я тебя видел

Давно

ну какбэ натягивание совы на глобус и забивание гвоздей микроскопом - изначально порочные практики. Конфиг - это конфиг, сорц - это сорц, нафига смешивать? Формат конфига универсален, читаем человеком независимо от знания конкретного языка и средствами других языков. А если конфиг изменится в процессе работы и его надо будет сохранить - редактировать сорц из-под себя как текстовый файл? Кончайте страдать ненужной фигнёй

Не фантазируй, и совах в частности.

а группа в группе может быть? я почему-то такого нигде не находил, на device1 например, нужно разделение конфигов по работе с бд и работе с форматированием api, к примеру

а как группу отличить от подгруппы? Емнип идентация считается комментом

Саша, где-то я тебя видел

Я в некоторых чатах есть, группах, ну и социален)

а как группу отличить от подгруппы? Емнип идентация считается комментом

Отличить уровнем вложенности.

а как группу отличить от подгруппы? Емнип идентация считается комментом

т.е. вместо [g1] [some_subgroup] лучше писать [g1] [g1.some_subgroup] ? (хотя это все равно единственный варик ахахах)

Саша, где-то я тебя видел

Вспомнил? У меня проблемы с памятью. Я хз кто ты. Напомни.

хорошо, тогда просто риторический вопрос, и отстану: в целом в разработке, не только в пайтоне, а вообще, как лучше конфиги писать? ну, т.е. у node'вцев есть правило писать .json, гоферы .yml, питонисты config.py, разве какого-то общего стандарта нет?

json тоже для конфигов так себе, саблим пошёл по этому пути, получилась ерунда

т.е. вместо [g1] [some_subgroup] лучше писать [g1] [g1.some_subgroup] ? (хотя это все равно единственный варик ахахах)

понятия подгрупп там в принципе нет, это плоский формат

json тоже для конфигов так себе, саблим пошёл по этому пути, получилась ерунда

vs code, в котором я работаю, состоит только из редактора файлов, настройки редактируются путем редактирования json))) в теории, кстати, удобно, можно быстро перелетать из одного окружения в другое разных проектов, но ска, чет здесь не так)

json тоже для конфигов так себе, саблим пошёл по этому пути, получилась ерунда

jabberd и некоторые другие вообще в XML держат. И норм

vs code, в котором я работаю, состоит только из редактора файлов, настройки редактируются путем редактирования json))) в теории, кстати, удобно, можно быстро перелетать из одного окружения в другое разных проектов, но ска, чет здесь не так)

да, они учли недостатки подхода и написали целую свою обёртку для редактирования конфига

понятия подгрупп там в принципе нет, это плоский формат

то есть вообще плевать, какие обозначения у "сгруппированых" групп?

Привет

Подскажите литературу по машинному обучение

Привет

хаюшки

Подскажите литературу по машинному обучение

о, шарю

Это хорошо??

то есть вообще плевать, какие обозначения у "сгруппированых" групп?

в смысле? Есть группа, есть параметры в этой группе

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

Вспомнил? У меня проблемы с памятью. Я хз кто ты. Напомни.

Не-а, не вспомнил

Я из западной Украины

Я из западной Украины

Отсель не видать.

в смысле? Есть группа, есть параметры в этой группе

ну когда у тебя view=by_amount в api_views и view=users_db в db_config, не особо клево) как пример, не больше.

Подскажите литературу по машинному обучение

тебе для практики или просто начать с теории?

Желательно практики, теорию изучаю в процессе обучения)

Желательно практики, теорию изучаю в процессе обучения)

по теории что-нибудь читал?

короче

ну когда у тебя view=by_amount в api_views и view=users_db в db_config, не особо клево) как пример, не больше.

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

топ-2 книжек от Рича: теория: Домингоса "верховный алгоритм". все супер-понятно, показаны разные подходы, кода нет. практика:make your own neural network Рашида. под конец только начинается код, но для понимания она важна. на русском такую не видел потом можешь начать читать документацию по tensorflow, после чего можешь опробовать dialogflow, кайфовая штука

Всякие статьи читал, сейчас и не вспомню, в основном в интернете... Хотел научиться классификации текста

топ-2 книжек от Рича: теория: Домингоса "верховный алгоритм". все супер-понятно, показаны разные подходы, кода нет. практика:make your own neural network Рашида. под конец только начинается код, но для понимания она важна. на русском такую не видел потом можешь начать читать документацию по tensorflow, после чего можешь опробовать dialogflow, кайфовая штука

Я даже не знаю с какой стороны начать

Всякие статьи читал, сейчас и не вспомню, в основном в интернете... Хотел научиться классификации текста

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

Для гипотетического примера: SERVERS = [ { 'ip': 127.0.0.1', 'port' 8000 }, { 'ip': 10.0.0.1', 'port' 8000 } ] PARAM1 = 'value' На сколько взорвётся мозг у того, кто попытается воспроизвести это в INI

Спасибо)

?☺️

Для гипотетического примера: SERVERS = [ { 'ip': 127.0.0.1', 'port' 8000 }, { 'ip': 10.0.0.1', 'port' 8000 } ] PARAM1 = 'value' На сколько взорвётся мозг у того, кто попытается воспроизвести это в INI

а в чём проблема?

Ничего себе, эта книга в ЛитРес стоит 349 рублей?

а в чём проблема?

Никакой проблемы. Переведи мой пример в INI

кстати, в зависимости от задачи, тут может лучше json

@nn130001 а есть с примерами, где есть код хотя бы

Никакой проблемы. Переведи мой пример в INI

[server1] port ip итд, с json очевидно ты лучше скажи, что делать, если нужно сохранить новые значения или юзер напишет там невалидный код или eval(...) или.....

какой-то культ говнокода

[server1] port ip итд, с json очевидно ты лучше скажи, что делать, если нужно сохранить новые значения или юзер напишет там невалидный код или eval(...) или.....

Невалидный код можно try выловить хотя бы. Новые значения без проблем через Jinja2 можно сохранить. eval не нужен

какой-то культ говнокода

Не знал, что здравый смысл вне закона.

? я спать

Невалидный код можно try выловить хотя бы. Новые значения без проблем через Jinja2 можно сохранить. eval не нужен

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