Форум сайта python.su
7
Здравствуйте,
Некая 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"}
Офлайн
294
Master_Sergius по моему это идиотизм, не стоит вопринимать pythonic-way как какуюто догму.
Если вам приходят данные в mixedCase то так их и обрабтывайте, ничего особо криминального в этом нет. Никто вас не расстреляет за это.. ИМХО
как говорил Джек Воробей, кодекс PEP8 это скорее руководство к действию, а не свод строгих правил.
Master_SergiusНу там чутка про иное, что типо можно если уже такое используется, чтобы не нарушать преобладающий стиль.
Но, вроде же, это можно, даже с учетом самого PEP8
[code python][/code]
Отредактировано PEHDOM (Май 11, 2021 20:13:57)
Офлайн
253
Помоему Pep8 касается имен переменных а никак не данных.
Если ключей 3 как в примере, то не так уж сложно привести к snake case. И я бы поддержал вашего тим лида, чтобы 3 переменные не были белыми воронами.
Но конечно бывают случаи когда переменных много и есть пользователи которые привыкли к их предопределенному виду. Тогда очевидно надо пользоваться как есть.
Например у нас питон используется как скриптовая часть к некой сложной модели. Там принято имена давать upper case и всего имен порядка двух миллионов. Понятно что используются имена предметной области.
Офлайн
857
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)
Офлайн
44
Master_Sergiusок префикс + ваша змеюка … а не … хм
настоящие проблемы появляются, когда оказывается
и вставьте ссылку на его url Отредактировано AD0DE412 (Май 12, 2021 10:37:51)
Офлайн
7
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)
Офлайн
294
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)
Офлайн
186
> Да, это тупо, но, возможно. … Но, лид говорит - никак нет, это не pythonic-way.
Для вас регистр букв такая большая проблема? Вам самим то не стыдно?
> На UI этого сервиса админы групп могут изменять профили пользователей, а именно добавлять/удалять какие-то кастомные аттрибуты
Каждый раз как админы что то поменяют вы модель обновляйте? Ну это вообще бред.
Офлайн
7
PEHDOM, сейчас оно так приблизительно и работает - кастомные атрибуты обрабатываются отдельно. Но выглядит это же очень некрасиво, как в примере выше.
Rodegast
Для вас регистр букв такая большая проблема? Вам самим то не стыдно?.
Потому что, как я уже описал выше - есть исключения: 1) кто-то создаст кастомные атрибуты, которые в приведение в один регистр будут одинаковы; 2) кто-то создаст атрибут, который будет такой же как базовый, после приведения в один регистр. Это, конечно, крайне маловероятно, но возможно. Я бы не хотел, чтобы такая дырка оставалась. И, возможно, есть ещё какие-то случаи, о которых пока никто не догадывается, но пользователи всегда попадают на какие-то новые грабли.RodegastНет, конечно, модель формируется динамически.
Каждый раз как админы что то поменяют вы модель обновляйте? Ну это вообще бред.
Офлайн
294
Master_SergiusЕсли модель формируется динамически то какая вам разница какими буквами там что заведено и что там внутри?
Нет, конечно, модель формируется динамически.
[code python][/code]
Офлайн