junior-1/python: creating roadmap

[stanislav-az]

Хотелось бы еще вопросы про виртуальные окружения: что такое, для чего, как использовать. Разница между venv, virtualenv, pipenv, conda, poetry

[stanislav-az]

И еще вопросы про линтеры, и как проверять что сходятся типы в аннотациях

[alagunoff]

Хотелось бы еще вопросы про виртуальные окружения: что такое, для чего, как использовать. Разница между venv, virtualenv, pipenv, conda, poetry

С первой частью согласен, можно добавить в первого джуна по питону. По второй не очень понял, это разные python модули, которые делают разные вещи)

[alagunoff]

И еще вопросы про линтеры, и как проверять что сходятся типы в аннотациях

"и как проверять что сходятся типы в аннотациях" Что ты тут услышать хочешь?

[stanislav-az]

это разные python модули, которые делают разные вещи

Разве все эти инструменты (venv, virtualenv, pipenv, conda, poetry) не для создания виртуальных окружений? Я когда гуглил про это натыкался на все эти названия, но в итоге использую venv, ты вроде мне его тоже рекомендовал.

[alagunoff]

@dashkevi4mike И нужно добавить ресурсы для изучения всех подтем

[alagunoff]

это разные python модули, которые делают разные вещи

Разве все эти инструменты (venv, virtualenv, pipenv, conda, poetry) не для создания виртуальных окружений? Я когда гуглил про это натыкался на все эти названия, но в итоге использую venv, ты вроде мне его тоже рекомендовал.

Я про venv только слышал и да, он для создания виртуального окружения используется. conda и poetry это вроде как альтернатива pip

[stanislav-az]

Что ты тут услышать хочешь?

Ну мне посоветовали проверять типы из аннотаций с помощью тайп чекера https://github.com/microsoft/pyright . Он включается в vs code если включить расширение pylance (ms-python.vscode-pylance). Это вместо этапа компиляции, к которому я привык) Но вообще, иногда это мешает: не все соблюдают конвенции с аннотациями типов.

[stanislav-az]

Я про venv только слышал и да, он для создания виртуального окружения используется. conda и poetry это вроде как альтернатива pip

Наверное, лучше спросить тогда просто про venv, так как он рекомендован в офицальной доке питона. Самый классный ответ про разницу этих инструментов я находил тут.

[alagunoff]

Что ты тут услышать хочешь?

Ну мне посоветовали проверять типы из аннотаций с помощью тайп чекера https://github.com/microsoft/pyright . Он включается в vs code если включить расширение pylance (ms-python.vscode-pylance). Это вместо этапа компиляции, к которому я привык) Но вообще, иногда это мешает: не все соблюдают конвенции с аннотациями типов.

Мне кажется это не совсем на первого джуна подходит. Ну т.е. человек будет уметь пользоваться языком, но ему не обязательно знать, что можно подключить проверку типов для питона. Я хоть и не стоял на боевом проекте по питону еще, но @dashkevi4mike говорит, что у него на текущем проекте не используется type checker. Поэтому это конечно хорошо его подключить, но не прям уж обязательно

[alagunoff]

@stanislav-az added questions about virtual environment

[stanislav-az]

Еще надо бы добавить вопросы про модульную систему и пакеты: как организовать иерархию модулей в пакете, для чего файл __init__.py, относительные обращения (.mod, ..mod), импорты (from, as, *)

[alagunoff]

Еще надо бы добавить вопросы про модульную систему и пакеты: как организовать иерархию модулей в пакете, для чего файл __init__.py, относительные обращения (.mod, ..mod), импорты (from, as, *)

Есть вводный вопрос же про то, что такое модули и пакеты

"как организовать иерархию модулей в пакете" Это вопрос уже не на первого джуна. Ему не нужно знать как правильно организовать, ему нужно уметь в питоне, когда его подключат на проект. В проекте уже будет заложена архитектура.

[olgaklimenko]

Что ты тут услышать хочешь?

Ну мне посоветовали проверять типы из аннотаций с помощью тайп чекера https://github.com/microsoft/pyright . Он включается в vs code если включить расширение pylance (ms-python.vscode-pylance). Это вместо этапа компиляции, к которому я привык) Но вообще, иногда это мешает: не все соблюдают конвенции с аннотациями типов.

Мне кажется это не совсем на первого джуна подходит. Ну т.е. человек будет уметь пользоваться языком, но ему не обязательно знать, что можно подключить проверку типов для питона. Я хоть и не стоял на боевом проекте по питону еще, но @dashkevi4mike говорит, что у него на текущем проекте не используется type checker. Поэтому это конечно хорошо его подключить, но не прям уж обязательно

Я за то, чтобы сразу учить писать аннотации к типам и проверять их. Особенно если мы хотим брать проекты под ключ, писать бэкенд с нуля - лучше сразу это изучить и пользоваться всей команде, начиная с 1го джуна. Если мы идём на поддержку чужого кода, где нет аннотаций и тайпчека - можно просто добавлять его потихоньку в свой код (у тайпчекера есть опция не требовать аннотации, но если они есть - проверять).

[alagunoff]

Что ты тут услышать хочешь?

Ну мне посоветовали проверять типы из аннотаций с помощью тайп чекера https://github.com/microsoft/pyright . Он включается в vs code если включить расширение pylance (ms-python.vscode-pylance). Это вместо этапа компиляции, к которому я привык) Но вообще, иногда это мешает: не все соблюдают конвенции с аннотациями типов.

Мне кажется это не совсем на первого джуна подходит. Ну т.е. человек будет уметь пользоваться языком, но ему не обязательно знать, что можно подключить проверку типов для питона. Я хоть и не стоял на боевом проекте по питону еще, но @dashkevi4mike говорит, что у него на текущем проекте не используется type checker. Поэтому это конечно хорошо его подключить, но не прям уж обязательно

Я за то, чтобы сразу учить писать аннотации к типам и проверять их. Особенно если мы хотим брать проекты под ключ, писать бэкенд с нуля - лучше сразу это изучить и пользоваться всей команде, начиная с 1го джуна. Если мы идём на поддержку чужого кода, где нет аннотаций и тайпчека - можно просто добавлять его потихоньку в свой код (у тайпчекера есть опция не требовать аннотации, но если они есть - проверять).

Так я тоже за это, безусловно. Что мы тут конкретно хотим, добавить пулл вопросов о том что это такое, как использовать и тд? Мне кажется, когда джуна подключат на проект, он сам там освоится в этом всем. Для каждого аспекта языка если добавлять вопросы, то топик разрастется очень сильно. Как по мне, это больше к best practices относится, нежели чем к теме

[olgaklimenko]

Что ты тут услышать хочешь?

Ну мне посоветовали проверять типы из аннотаций с помощью тайп чекера https://github.com/microsoft/pyright . Он включается в vs code если включить расширение pylance (ms-python.vscode-pylance). Это вместо этапа компиляции, к которому я привык) Но вообще, иногда это мешает: не все соблюдают конвенции с аннотациями типов.

Мне кажется это не совсем на первого джуна подходит. Ну т.е. человек будет уметь пользоваться языком, но ему не обязательно знать, что можно подключить проверку типов для питона. Я хоть и не стоял на боевом проекте по питону еще, но @dashkevi4mike говорит, что у него на текущем проекте не используется type checker. Поэтому это конечно хорошо его подключить, но не прям уж обязательно

Я за то, чтобы сразу учить писать аннотации к типам и проверять их. Особенно если мы хотим брать проекты под ключ, писать бэкенд с нуля - лучше сразу это изучить и пользоваться всей команде, начиная с 1го джуна. Если мы идём на поддержку чужого кода, где нет аннотаций и тайпчека - можно просто добавлять его потихоньку в свой код (у тайпчекера есть опция не требовать аннотации, но если они есть - проверять).

Так я тоже за это, безусловно. Что мы тут конкретно хотим, добавить пулл вопросов о том что это такое, как использовать и тд? Мне кажется, когда джуна подключат на проект, он сам там освоится в этом всем. Для каждого аспекта языка если добавлять вопросы, то топик разрастется очень сильно. Как по мне, это больше к best practices относится, нежели чем к теме

Мне наоборот кажется, что это не к best practices относится, а к must have. Также как и venv - ты можешь его не настраивать и использовать глобальное окружение, но лучше сразу научиться разделять окружения и понимать почему это нужно, чем потом узнать это на проекте. При этом на 1 джуне как раз происходит изучение основных типов, почему бы сразу не чекнуть типы функций, в которых ты их используешь.

[alagunoff]

Что ты тут услышать хочешь?

Ну мне посоветовали проверять типы из аннотаций с помощью тайп чекера https://github.com/microsoft/pyright . Он включается в vs code если включить расширение pylance (ms-python.vscode-pylance). Это вместо этапа компиляции, к которому я привык) Но вообще, иногда это мешает: не все соблюдают конвенции с аннотациями типов.

Мне кажется это не совсем на первого джуна подходит. Ну т.е. человек будет уметь пользоваться языком, но ему не обязательно знать, что можно подключить проверку типов для питона. Я хоть и не стоял на боевом проекте по питону еще, но @dashkevi4mike говорит, что у него на текущем проекте не используется type checker. Поэтому это конечно хорошо его подключить, но не прям уж обязательно

Я за то, чтобы сразу учить писать аннотации к типам и проверять их. Особенно если мы хотим брать проекты под ключ, писать бэкенд с нуля - лучше сразу это изучить и пользоваться всей команде, начиная с 1го джуна. Если мы идём на поддержку чужого кода, где нет аннотаций и тайпчека - можно просто добавлять его потихоньку в свой код (у тайпчекера есть опция не требовать аннотации, но если они есть - проверять).

Так я тоже за это, безусловно. Что мы тут конкретно хотим, добавить пулл вопросов о том что это такое, как использовать и тд? Мне кажется, когда джуна подключат на проект, он сам там освоится в этом всем. Для каждого аспекта языка если добавлять вопросы, то топик разрастется очень сильно. Как по мне, это больше к best practices относится, нежели чем к теме

Мне наоборот кажется, что это не к best practices относится, а к must have. Также как и venv - ты можешь его не настраивать и использовать глобальное окружение, но лучше сразу научиться разделять окружения и понимать почему это нужно, чем потом узнать это на проекте. При этом на 1 джуне как раз происходит изучение основных типов, почему бы сразу не чекнуть типы функций, в которых ты их используешь.

Ну согласен, ок. Может сама сделаешь коммит, а я посмотрю и поправлю, чтобы духу темы соответствовало? Я просто не очень понимаю как это лучше сформулировать

[olgaklimenko]

Добавила топик про аннотацию типов.

[alagunoff]

@olgaklimenko Круто, спасибо за вклад в пр!) Чуть поправил, а именно:

• Убрал прослойку questions в list of contents, тк у нас заголовок темы и есть "Вопросы", а содержание как раз таки темы - basics и т.д.
• Вынес вопрос про типизацию функции в отдельную задачу в "Practice"
• Убрал вопросы про mypy, тк это ну больно уж узкая тема. Я его вообще не использую, к примеру, в vscode есть расширение pylance, которое pyright под капотом использует. Так что, я думаю, тут уже дело вкуса, главное, чтобы человек знал о type annotations и умел их использовать себе во благо)

И + разнес вопросы по модулям и пакетам, виртуальной среде в отдельные секции. Ждем пока @dashkevi4mike поправит джангу)

[olgaklimenko]

@alagunoff @dashkevi4mike Давайте мёржить?