Понять бы какую заглушку

я могу закинуть еще в куа-чаты

если надо

было  бы супер =)

в общем, я не знаю можно ли такое делать не используя typing.Generic

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

Используя точно нельзя

Я почитал про airflow. А почему переходите с luidgi (про luidgi помню был на докладе Никиты). Просто на переколбашивание всех пайплайнов и инфры просто так не решаются, должны быть веские причины.

Meanwhile in C language

a[1]==1[a]

Ага)

Выкладываем в открытый доступ на youtube очередную и заключительную порцию видео по итогам PiterPy 2019

1) Николай Сасковец​ / Passionate Software Engineer
Строим микросервисное приложение используя Kafka и Django
https://youtu.be/CeOJlLVy6fw

2) Сергей Халецкий / EPAM
GraphQL + Python сегодня. Реализация Public API с помощью GraphQL
https://youtu.be/vNK0kc2Zmz4

3) Денис Катаев​ / Tinkoff.ru Разработчики имеют такие логи, на какие у них хватает фантазии
https://youtu.be/ryVnQShxZA8

4) Дмитрий Карпов / Wargaming
Перевод проекта со 2 на 3 Python
https://youtu.be/auVSCqUQ6F4

5) Александр Толмачев / Xsolla
Автоматический прогноз оборота бустинговыми моделями и DL
https://youtu.be/9SWZEAz6Vac

6) Константин Тяпочкин, Алексей Смирнов / Profiscope
Зачем роботам читать ваш код?
https://youtu.be/R8A0fAfA8Kk

все выкладывают видео 🌚

видео мои видео

👍🏻

Спасибо

Technical Board statement on type hints for Django

Sorry for the late answer, I didn't have time to read this mailing list for the last month :-( Here's my position on the matter.

Adding type annotations only makes sense if a type checker checks them. Otherwise, they're unlikely to be correct and usable, so it would be counterproductive to add them. Unfortunately, I don't think we have a good enough type checker yet.

I'm having a rough experience maintaining type checking with mypy in websockets <https://github.com/aaugustin/websockets>, a library that is very much smaller and simpler than Django. (Some problems are related to async, which isn't a concern for Django, but that doesn't explain everything.)

* Besides adding the type annotations, type checking required many other code changes. Importing types in modules that need them created circular dependencies. Fixing these import loops required moving imports to the bottom (ugh), splitting code in small modules (meh), or always importing modules rather than objects inside modules (perhaps a good practice, but changing this throughout a project creates a lot of noise). Also, import loops tend to reappear when implementing new features or refactoring.

* It's an uphill struggle to keep up with subtle changes of behavior in mypy — which is still 0.x software. I also encountered regressions that required pinning to an old version. Supporting more than one mypy version seems out of reach. I'm very pessimistic about supporting more than one type checker.

* I don't remember mypy catching interesting bugs. I'm keeping it only because I'm failing to deal with the sunk cost logical fallacy :-( Overall, adding type annotation to websockets has decreased my ability and willingness to maintain it. I believe it increased the barrier to entry for other contributors as well.

So, I think the ecosystem needs to stabilize a lot before Django can adopt static typing, even just as a best practice for new code. Comments like this one <https://github.com/django/deps/pull/65/files#r333706194> make me uncomfortable about living that close to the edge.

Also, given that static typing was bolted on Python very late in its history and that there's a strong tradition of relying on duck typing, I'm not yet convinced static typing will ever be widely accepted as a best practice.

> splitting code in small modules (meh)

Ну что, ещё пару лет подождать что ли

А есть, интересно, истории успеха с растом на бэке?