GF
Это как вместо того, чтобы пнуть мяч ногой, пойти взять доску, привязать ее к ноге, и рукой доску замахнуть, чтоб в итоге НОГА УДАРИЛА ПО МЯЧУ
Size: a a a
2020 August 28
GF
Ну да, оно ведь следую зену
Это был сарказм, если что
W
написать класс, при инициализации объекта которого, из message будут вытягиваться вся необходимая инфа:
class User:Таким образом это:
def __init__(self, message):
self.id = message.from_user.id
self.first_name = message.from_user.first_name
bot.send_message(message.from_user.id, f' Здравствуйте {message.from_user.first_name}')
сократиться до: user = User(message)
bot.send_message(user.id, f' Здравствуйте {user.first_name}')>непонятный юзер
3 строки кода, кард
заместо повсеместного упоминания message.from_user
только в этом примере с 2-мя использованиями объекта класса, уже код сократился на 5 символов
3 строки кода, кард
заместо повсеместного упоминания message.from_user
только в этом примере с 2-мя использованиями объекта класса, уже код сократился на 5 символов
W
в проектах на 1000 строк это существенно сократит объем кода и улучшит его читаемость
GF
в проектах на 1000 строк это существенно сократит объем кода и улучшит его читаемость
Нет
GF
Нихуя это не улучшит читаемость
GF
И сократит очень незначительно
GF
Отдельный парсящий класс имел бы смысл, если бы ты хотел что-то такое, например:
def get_full_name(self):
full_name = self.first_name
if self.last_name:
full_name += f" {self.last_name}"
return full_name
GF
Но когда ты вместо прямого обращения к атрубуту создаёшь класс, который сделает это вместо тебя, и обращаешься уже к его атрибуту - это чет охуеть какая жесть
GF
Но когда ты вместо прямого обращения к атрубуту создаёшь класс, который сделает это вместо тебя, и обращаешься уже к его атрибуту - это чет охуеть какая жесть
Ну я уже привел пример с доской
GF
И, кстати, не на 5, а на 4 :D
W
Но когда ты вместо прямого обращения к атрубуту создаёшь класс, который сделает это вместо тебя, и обращаешься уже к его атрибуту - это чет охуеть какая жесть
не забывай, что при старте зачастую нужно ложить юзера в бд, этот класс стал бы наилучшим местом для хранения подобного метода
не в мейне же это делать, как это делают некоторые юзеры этого чата(пальцем показывать не буду)
не в мейне же это делать, как это делают некоторые юзеры этого чата(пальцем показывать не буду)
W
Отдельный парсящий класс имел бы смысл, если бы ты хотел что-то такое, например:
def get_full_name(self):
full_name = self.first_name
if self.last_name:
full_name += f" {self.last_name}"
return full_name
для того конкретного примера большее колличество кода и не нужно
в дольнейшем мб был бы смысл подобные ф-ции реализовывать
в дольнейшем мб был бы смысл подобные ф-ции реализовывать
W
Нихуя это не улучшит читаемость
вкусовщина, но анивей зен
GF
не забывай, что при старте зачастую нужно ложить юзера в бд, этот класс стал бы наилучшим местом для хранения подобного метода
не в мейне же это делать, как это делают некоторые юзеры этого чата(пальцем показывать не буду)
не в мейне же это делать, как это делают некоторые юзеры этого чата(пальцем показывать не буду)
Для хранения метода, связанного с бд, наилучшим местом был бы класс, предназначенный для связки с бд
W
Для хранения метода, связанного с бд, наилучшим местом был бы класс, предназначенный для связки с бд
а методы врапера уже из мейна вызывать?
неплохо
неплохо
W
И, кстати, не на 5, а на 4 :D
8, если не считать пробелы
GF
8, если не считать пробелы
GF
Language:
Source:
Result:
py3
Source:
print(len("user = User(message)") - len("user = message.from_user"))Result:
-4
GF
Откуда 8