- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
def __init__(self, text: str, description: str, category_id: int, auth_cookie: str) -> None:
Form.__init__(self)
CsrfForm.__init__(self)
CaptchaForm.__init__(self)
self.text: str = text
self.description: str = description
self.category_id = category_id
self.auth_cookie = auth_cookie
Нужно конструкторы предков вызвать, и все поля вручную проставить.
Кажется, потому датаклассы и завезли, не?
>self.text: str =
>self.category_id
обожаю это говно
где-то пишем тип, где-то не пишем...
Это неявная типизация же, тип выводится из типа аргумента коньструктора. Хотя с text и description проёб, да.
Ну, знаешь, как сначала делают везде обязательные явные типы, лет десять-двадцать их кушают, а потом изобретают var/let/val/auto.
Правда, я гаедлайны по питоновской типизации не читал, так что хз.
угу. Но у тебя еще не самый адский вариант, я видал код, где часть параметров даже не выводится.
А у тебя VSCode умеет эти аннотации парсить, и делать кодинсайт? Пайшарм вот умеет.
Вывод типов это всё таки другое: там статическая типизация обязательна, просто ее можно посчитать. А в питоне ж нет.
>гаедлайны
Хуй знает, где есть такие. Я бы почитал. Пока что кажется, что в публичном API лучше всегда указывать типы, а в скриптушне для себя -- нет
Разумеется, там и официальные расширения (от «Майкрософта») для этого есть, и ещё куча разных. Я использую стандартный «mypy», он довольно качественно работает. «Pyright» не понравился, какие-то траблы были, а вот сейчас активно развивается «Pylance» — надо бы глянуть как-нибудь.
> а в скриптушне для себя -- нет
Я и в скриптушне добавляю. Периодически отлавливаю разные глупые очепятки. А вообще стараюсь делать так, чтобы у каждой пельменной «mypy» хотя бы выводил тип.
Мне просто сказалось, что mypy делался не для ide, а для валидации кода потом, как линтер
>Я и в скриптушне добавляю.
Может, пора на typescript?
> Мне просто сказалось, что mypy делался не для ide, а для валидации кода потом, как линтер
Ну, ЕМНИП, оно так и есть, только в «VSCode» его прикрутили динамически.
> Может, пора на typescript?
Не, воздержусь.
А если серьёзно, то у путуха чуть более сложный деплой: надо «gunicorn» ставить, юниты создавать, все дела.
Ты можешь использовать mod_python, и будет тоже самое что и с пыхокалом.
А если в пыхокале ты будешь использовать fcgi_fpm то его тоже надо ставить, и юниты создавать
Любопытно, не слышал про такое извращение.
> Я не понял, причем тут язык.
Скорее, не язык, а сложившаяся практика его применения.
Есть еще mod_wsgi, кажется он депрейетнул mod_python.
>практика
Это правда
Хотя про запуск пыха в отдельном процессе и связывании его по fast cgi даже Конардо говорил
Правда, это в больших проектах конечно
>я беру «C++».
ты сравнил) есть же всякие золотые середины типа kotlin, правда нужно жвм иметь
Подтверждаю. Для мелких проектов вроде «NGK» это несколько излишне (хотя наш инженерный отдел уже давно хочет прикрутить эту тему, хотя бы для общего развития). А сейчас наши путухоновские проекты деплоятся как в этой статье: https://habr.com/post/512550/ (только без шкриптов и ЙАЖИ).
А в другом петпроекте делается тоже самое, но удаленно: там используется fabric, и запускать его нужно на своей машине, по историческим причинам.
Ага. А потом засирают этими var/let/val/auto код настолько, что чтобы его понять, приходится вводить обязательные гайдлайны на уровне проекта, где описывать кейсы, когда эти самые var/let/val/auto нужно применять, а когда — лучше написать просто int.
Читаешь ревью в браузере. Грузить ветку в IDE то не особо удобно.
Я забыл, что сишники и крестовики скилловые и думают про переполнения
С более сложными типами обычно всё более-менее очевидно по имени функции или по полям которые оттуда достают. Но если там несколько похожих типов - приходится лезть в описание опять же.
З.Ы. Ну и если первый раз этот код видишь и с типами которые там юзаются ещё не знаком, auto сильно затрудняет понимание.
Если я не могу без IDE понять тип выражения, то может нахуй оно?