Ну если все в контейнерах - то он нахер не нужон нам, venv ваш

Нет ничего плохого, чтобы pip’ом загонять пакеты в окружение, которые ты полностью контроллируешь. Типа докер-образа

venv - это способ изоляции разных питонов. Например, можно иметь разные версии в разных venv’ах. pip-то тут причем

Кстати, мне кажется что существует тайное общество саботажников, в котором маленьких питоняшек первым делом учат использовать конду в какой-то из её ипостасей и просто ставить зависимости. А потом все такие: "шо это за херня, где изоляция, какая еще в жопу конда"

У меня была мысль написать экспериментальную реализацию import-а (вроде такое можно сделать в питоне). Что бы она смотрела кто вызывает импорт, например это foo-1.0. После чего смотрела на его зависимости, например там будет bar-1.0. И соответственно импортировало bar-1.0. А если импорт bar-а делает пакет image, у которого в зависимостях написано bar-2.0, то для этого пакета выдавать именно bar-2.0.
Это всё по аналогии с тем как это работает для Rust и других языков, где имя и версия пакета не является, чем-то глобальным и определяется только в рамках другого пакета, для которого он нужен.

Тут конечно могут быть проблемы, если foo возвращает объекты из bar, и мы потом эти объекты захотим прокинуть в image, которая использует внутри себя новую версию bar с несовместимыми типами bar-объектов. Питон без статической типизации не сможет нас от этого защитить на этапе "компиляции". Но может это будет не так страшно, и не так часто встречаться, и вообще "утка спасёт мир".

Из плюсов такого решения - можно будет ставить одновременно разные версии одного и того же пакета и не разруливать с матами несовместимые зависимости зависимостей.

но если мультистейдж билд, то удобнее с ним )
я правда не помню, зачем мне был нужен такой кейс, но он был

вроде какая-то хрень не ставилась без gcc и на первом стейдже был обычный (не slim) образ, apt install build-essentials и вот это всё, а на втором получившийся venv копировался в slim

Норм кейс. Наверное можно и без него, но видимо так было проще)

без мультистейджа надо все в одном слое делать, а я не люблю большие RUN где сначала ставятся devel зависимости, потом удаляются )
может быть можно без венва и копировать site-packages или как там оно называется, но что-то мне тогда с венвом стрельнуло в голову сделать )

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

Я про venv, а не мультистейдж. Без мультистейджа низзя, нефиг размер имаджей раздувать

есть ли в питоне named return values как в гошке https://tour.golang.org/basics/7 ? если нет, то почему нинужен?

я думаю что так как defer и recover нет, то и смысла в этом особого нет

А как это потом испрьзовать?

это троллинг? берёшь и используешь. по ссылке даже пример есть

нет.
func main() {
 split(19)
 fmt.Println(x)
 fmt.Println(y)
}

./prog.go:13:14: undefined: x
./prog.go:14:14: undefined: y

Я GO не знаю. Чем плохо вернуть tuple&

в общем ИМХО они нужны для вот таких кейсов, поэтому в питонии их не к чему прикладывать
https://stackoverflow.com/a/33167433/4478375

это синтаксический сахар, там и вернется пара элементов, просто можно их в ретурне не писать

я бы заюзал для объявления не только типа, но и имени и дефолтного значения возвращаемой переменной в заголовке функции