Форум сайта python.su
Здравствуйте,
Некая API возвращает ответы в json-формате, где имена переменных в lowerCamelCase:
{"userId": "xxx", "firstName": "John", "lastName": "Connor"}
class User: first_name = None last_name = None
{"userId": "xxx", "firstName": "John", "first_name": "Jonny", "lastName": "Connor"}
Офлайн
Master_Sergius по моему это идиотизм, не стоит вопринимать pythonic-way как какуюто догму.
Если вам приходят данные в mixedCase то так их и обрабтывайте, ничего особо криминального в этом нет. Никто вас не расстреляет за это.. ИМХО
как говорил Джек Воробей, кодекс PEP8 это скорее руководство к действию, а не свод строгих правил.
Master_SergiusНу там чутка про иное, что типо можно если уже такое используется, чтобы не нарушать преобладающий стиль.
Но, вроде же, это можно, даже с учетом самого PEP8
[code python][/code]
Отредактировано PEHDOM (Май 11, 2021 20:13:57)
Офлайн
Помоему Pep8 касается имен переменных а никак не данных.
Если ключей 3 как в примере, то не так уж сложно привести к snake case. И я бы поддержал вашего тим лида, чтобы 3 переменные не были белыми воронами.
Но конечно бывают случаи когда переменных много и есть пользователи которые привыкли к их предопределенному виду. Тогда очевидно надо пользоваться как есть.
Например у нас питон используется как скриптовая часть к некой сложной модели. Там принято имена давать upper case и всего имен порядка двух миллионов. Понятно что используются имена предметной области.
Офлайн
Master_SergiusНу, всё правильно.
Ну и кто-то когда-то решил сделать представление модели такого user-a в “pythonic-way”, то есть все параметры в snake_case:
Master_SergiusТак ты должен преобразовать их дальше. Если у тебя появляется тупорылый API, то это не значит, что ты свой код за ним следом должен делать тупорылым. У тебя должны быть преобразователи туда и обратно. Ещё много таких ситуаций будет. Что, под каждый отдельный API будешь код менять? А когда разные API начнут другу противоречить и склэшатся, что ты тогда будешь делать? Вообще программу писать перестанешь? Поэтому делай адаптеры на вход и на выход. А код держи в чистоте со всеми правилами.
Естественно, для ответ от API приводят к snake_case виду, что уже немного нехорошо.
Master_SergiusКонечно, не прав. Выброси ещё все линтеры, они же тоже пишут, что у тебя всё неправильно. Но, я думаю, ты ими просто не пользуешься ещё.
Я прав/не прав?
Отредактировано py.user.next (Май 11, 2021 23:17:39)
Офлайн
Master_Sergiusок префикс + ваша змеюка … а не … хм
настоящие проблемы появляются, когда оказывается
Отредактировано AD0DE412 (Май 12, 2021 10:37:51)
Офлайн
py.user.nextЗачем сразу бросаться оскорблениями, товарищ? Я пользовался линтерами “ещё до того, как это стало мейнстримом”. Тут дело в другом, позвольте мне описать более подробно всю суть проблемы и крик души моей.
Выброси ещё все линтеры, они же тоже пишут, что у тебя всё неправильно. Но, я думаю, ты ими просто не пользуешься ещё.
users = group_and_users_client.list_users() # сырой ответ от API: [{"userId": "xxx", "firstName": "John", "lastName": "Connor"}] # в переменной users будет список объектов типа User такого вида: for user in users: print(user.first_name) print(user.last_name)
user.first_name = "Sarah" result = group_and_users_client.update_user(user_id=user.user_id, user)
user.first_name = "Sarah" user.FloorNumber = 5 result = group_and_users_client.update_user(user_id=user.user_id, user)
Отредактировано Master_Sergius (Май 12, 2021 12:21:02)
Офлайн
Master_Sergius ну тут нужно смотреть для чего и как у вас используется представление модели.
Вы вполне логично представили закономерную ситуацию что ктото заведет кастомный атрибут “floor_number” и тогда “case casting” сломается. Это реальная дыра в системе(допустим ктото заведет кастомный артибут user_іd) и оно может поломать вышестоящую систему.
Давайте я вам добавлю еще один кейс: завтра АПИ поменяется и будет возвращать данные в виде: {“UserId”: “xxx”, “FirstName”: “John”, “LastName”: “Connor”…} вам тогда что всю программу переписывать?
Очевидно мухи долнжы быть отдельно, а котлеты отдельно. Тоесть у вас должен быть конектор который будет делать маппинг базовых параметров в обе стороны и если АПИ поменяется то вам придется переписать только конектор. Но вы не можете предсказать в каком виде будут кастомные парметры и перводить их в lower_case_with_underscores или в какойто иной вид верх идиотизма. Они должны храниться отдельно “как есть”, чтобы вы четко понимали где у вас обязательные атрибуты, а где пользовательские, и в таком же виде обрабатываться/отдаваться в каком и приходят.
[code python][/code]
Отредактировано PEHDOM (Май 12, 2021 12:59:40)
Офлайн
> Да, это тупо, но, возможно. … Но, лид говорит - никак нет, это не pythonic-way.
Для вас регистр букв такая большая проблема? Вам самим то не стыдно?
> На UI этого сервиса админы групп могут изменять профили пользователей, а именно добавлять/удалять какие-то кастомные аттрибуты
Каждый раз как админы что то поменяют вы модель обновляйте? Ну это вообще бред.
Офлайн
PEHDOM, сейчас оно так приблизительно и работает - кастомные атрибуты обрабатываются отдельно. Но выглядит это же очень некрасиво, как в примере выше.
Rodegast
Для вас регистр букв такая большая проблема? Вам самим то не стыдно?.
RodegastНет, конечно, модель формируется динамически.
Каждый раз как админы что то поменяют вы модель обновляйте? Ну это вообще бред.
Офлайн
Master_SergiusЕсли модель формируется динамически то какая вам разница какими буквами там что заведено и что там внутри?
Нет, конечно, модель формируется динамически.
[code python][/code]
Офлайн