Вы меня уделали. У меня в голове Банда четырёх была почему-то связана с ростом популярности Java, и я до сих пор не удосужился сличить даты. Позор мне.
Гамма работал в IBM, занимался VisualAge, Eclipse и JDT. Видимо, оттуда мои ассоциации с Java. Хотя было это, конечно, добрый десяток лет спустя.
Джонсон грокал смолток, остальные трое − джависты. Влиссидис имел бэкграунд в C++, но, наверное, больше работал с джавой на момент написания книги.
Я очень часто вижу, как программисты пытаются обособить себя от своего основного ЯП. С одной стороны, через академизацию своего опыта, мол, мы не программисты, мы computer scientists, мы не изучаем языки, а создаём их. С другой стороны, через ремесленничество − best tool for the job и прочие максимы. Но на практике я ни разу не наблюдал, чтобы кому-то удалось превзойти то форматирующее влияние, которое оказывает на способ мышления его основной инструмент. Одни мыслят категориями статически типизированных языков в динамически типизированных, другие − наоборот. Третьи плодят миллионы классов, ну и т. д.
Для понимания собственно ООП вполне хватает здравого смысла и среднеобывательского словарного запаса.
Вот паттерны − это специфическая вещь. Начиная с того, что книжка Банды Четырёх − это продукт борьбы (как минимум троих) авторов с особенностями и недостатками языка Java. Соответственно, понятна она только в этом контексте.
То есть некий супер-pip при доставке должен пройтись по проекту и поредактировать код? А в вызовы importlib, наверное, чего-нибудь добавить эвристически, или посендбоксить их?
Автор пакета или автор кода? Это разные роли. Автор пакета может вообще не знать Python, он может быть девопсом, например, и решать пакетированием чисто задачи доставки кода на стейдж/прод. А import должен писать джун, у которого вообще нет полномочий, чтобы решать, какую версию пакета использует проект.
Параметризовать import − это плохое решение, оно смешивает разные уровни. Импорт пакета − это код, а версия пакета − это инфраструктура. Когда, чтобы поменять что-то в инфраструктуре, приходится лезть в код − это называется «прибили гвоздями».
Иначе говоря, ждём появления в Python новой системы управления зависимостями, альтернативной pip/virtualenv/pyenv? Ну, ок тогда, пусть расцветают сто цветов.
Мне кажется, вы не очень представляете, что сравниваете. Если virtualenv − костыль, то только по сравнению с системами, стоящими на соответствующем уровне абстракции по отношению к CPython и пользовательскому коду. LXC, например. Это было бы понятно: Docker стартовал только в 2013, а virtualenv − в 2007, когда дешёвого способа создать среду исполнения ещё не было. Вы же сравниваете одну фичу интерпретатора языка со сложным компонентом, управляющим средой, в которой этот интерпретатор запускается.
Если существующие способы работы с зависимостями в Python слишком сложны (в чём я вообще-то сомневаюсь, но готов допустить), то как добавление ещё одного способа сделает жизнь проще?
Очень странный PEP. Выглядит как ползучий фичеризм и неосиляторство. В случаях, описанных в мотвационной части, пользователю либо достаточно pip install --user, либо всё равно придётся учить virtualenv. Если же хочется чего-то странного, то можно и поиграть с sys.path, как предлагает ОП. Зачем нужен ещё один глобальный механизм, непонятно.
Гамма работал в IBM, занимался VisualAge, Eclipse и JDT. Видимо, оттуда мои ассоциации с Java. Хотя было это, конечно, добрый десяток лет спустя.
Я очень часто вижу, как программисты пытаются обособить себя от своего основного ЯП. С одной стороны, через академизацию своего опыта, мол, мы не программисты, мы computer scientists, мы не изучаем языки, а создаём их. С другой стороны, через ремесленничество − best tool for the job и прочие максимы. Но на практике я ни разу не наблюдал, чтобы кому-то удалось превзойти то форматирующее влияние, которое оказывает на способ мышления его основной инструмент. Одни мыслят категориями статически типизированных языков в динамически типизированных, другие − наоборот. Третьи плодят миллионы классов, ну и т. д.
Вот паттерны − это специфическая вещь. Начиная с того, что книжка Банды Четырёх − это продукт борьбы (как минимум троих) авторов с особенностями и недостатками языка Java. Соответственно, понятна она только в этом контексте.
importдолжен писать джун, у которого вообще нет полномочий, чтобы решать, какую версию пакета использует проект.import− это плохое решение, оно смешивает разные уровни. Импорт пакета − это код, а версия пакета − это инфраструктура. Когда, чтобы поменять что-то в инфраструктуре, приходится лезть в код − это называется «прибили гвоздями».Мне кажется, вы не очень представляете, что сравниваете. Если virtualenv − костыль, то только по сравнению с системами, стоящими на соответствующем уровне абстракции по отношению к CPython и пользовательскому коду. LXC, например. Это было бы понятно: Docker стартовал только в 2013, а virtualenv − в 2007, когда дешёвого способа создать среду исполнения ещё не было. Вы же сравниваете одну фичу интерпретатора языка со сложным компонентом, управляющим средой, в которой этот интерпретатор запускается.
pip install --user, либо всё равно придётся учитьvirtualenv. Если же хочется чего-то странного, то можно и поиграть сsys.path, как предлагает ОП. Зачем нужен ещё один глобальный механизм, непонятно.