да, кое-где и Centos еще 6-й используют во всю, но это не значит, что это что-то показывает

https://github.com/google/ggrc-core

очень полезная всеми используемая штука, дико популярная?

очень полезная всеми используемая штука, дико популярная?

проектов на python там уйма, я ведь не буду все сюда кидать)

да, не все пользуются популярностью вне google, но почти все написаны на python 2

ну так гугл же, appengine, свой стек

пока гугловый внутренний стек не станет ориентирован на Py3, там нечего ловить.

проекты гугла - это еще далеко не весь гитхаб, внезапно

Жирно

Очень жирно

Легасиговно было и будет всегда

да, не все пользуются популярностью вне google, но почти все написаны на python 2

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

Вот как раз у нас центос 6 и питон 2.6.6

только недавно прикрутили механизм сборки под el6 и el7

вот еще можно почитать https://www.paypal-engineering.com/2014/12/10/10-myths-of-enterprise-python/

поддержка 2.х в библиотеках это боль, пуздон 2 должен умереть

страшно же смотреть на эти компат-извращения

Myth #6: Python is slow First, a critical distinction: Python is a programming language, not a runtime.

на питоне 2 было написано ну очень много всего и многие до сих пор это используют и не обновляют версии, а значит и версию питона, а значит они пилят туда еще и всякие плагины и патчи на 2-м питоне. вообще, это как с C++. много ли кода действительно активно использующего C++11 хотя бы? Так может и не надо на нем писать? А вот активная разработка в открытых проектах как раз про последние стандарты.

кстати да

нужно двигать новые технологии!

поддержка 2.х в библиотеках это боль, пуздон 2 должен умереть

ну 2.7 еще более менее, хотя вот MyPy под 2.7 - это ну прямо совсем забавно

нужно двигать новые технологии!

конечно:)

ну 2.7 еще более менее, хотя вот MyPy под 2.7 - это ну прямо совсем забавно

ну это реально челлендж

А с докером так и вовсе по фигу. Ну нааписано что-то на 3.5, ну запусти его под 3.5.

а там надо типа #type: (str, str)

чёт такое?

я натыкался на пеп прост, поржал и не вчитывался.

ну да, там каменты к сигнатуре, каждая аннотация на отдельной строке

занятно

с докером вообще пофигу, да

ну и сигнатура размазана по строкам

поэтому всё надо писать на Py3.6, C++17 и ES2017 :)

кек

не ссать и писать

пиши на си, пиши не ссы

особенно длинные проекты. если начинаешь проект на пол года, значит надо брать версии всего, которые зарелизятся в процессе

динамическая линковка это бич

а тем более на год...

всё было бы проще.

динамическая линковка это бич

докер же:)

ну да.

но докер это там всякие сервисики.

а софт на тачку немношк другое.

но докер это там всякие сервисики.

странно такое от человека с таким ником читать:)

кек

а софт на тачку немношк другое.

ну там же есть сейчас как оно называется...

ник прост свободен был

что?

Flatpak во

http://flatpak.org/

ого

интересно

вообще интересно сколько будут играть на подливе еще

с этими дистрибутивами

прикольно

ещё один пакетный менеджер

вообще интересно сколько будут играть на подливе еще

есть разные мнения https://solus-project.com/forums/viewtopic.php?t=1508

выглядит интересно

пробовал?

пробовал?

нет. даже не ставил ничего.

я прост почитал про stali

там есть интересные мысли

но границы не соблюдаются

Не только проекты гугла на python 2. OpenStack, Rackspace и другие компании работающие с облачными вычислениями пишут на python 2. Аналогия с C++ очень плохая, просто потому что C++ пытаются сделать мультипарадигмальным, а это с каждой версией все хуже и хуже выглядит

и всё скачивается в дрочево

типа конфигов в сорцах.

Не только проекты гугла на python 2. OpenStack, Rackspace и другие компании работающие с облачными вычислениями пишут на python 2. Аналогия с C++ очень плохая, просто потому что C++ пытаются сделать мультипарадигмальным, а это с каждой версией все хуже и хуже выглядит

ваше мнение понятно

ERROR: S client not available

странная позиция

плюсы становятся только лучше

теперь на них хоть писать можно

проекты гугла никого не интересуют.

кроме гугла)

кроме гугла)

тут есть варианты:)

эти боянисты даже protobuf написали

зачем-то.

лишь бы забоянить что-то

:)

у меня предвзятое отношение к C++)

Не только проекты гугла на python 2. OpenStack, Rackspace и другие компании работающие с облачными вычислениями пишут на python 2. Аналогия с C++ очень плохая, просто потому что C++ пытаются сделать мультипарадигмальным, а это с каждой версией все хуже и хуже выглядит

не будем тут еще и за плюсы холиварить, но про питон. тут никто не спорит, что еще много где пишут на 2-ке. но опять, это не повод за него топить, а скорее наоборот

у меня предвзятое отношение к предвзятому отношению.

Согласен. Тут скорее все зависит от компании и области в которой используется Python

почему open не открывает файл через pathlib.Path?

почему open не открывает файл через pathlib.Path?

Эээ?

почему open не открывает файл через pathlib.Path?

что пишет-то?

>>> with Path().open() as f

это ответ на другой вопрос интересует, почему именно open не умеет это

здесь объясняют, почему не наследуется от str: http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str но почему open не принимает Path пока непонятно

это ответ на другой вопрос интересует, почему именно open не умеет это

https://docs.python.org/3.6/whatsnew/3.6.html#pep-519

о

здорово, спасибо

Да, я тоже было предположил поначалу, что вся stdlib возьмет и будет работать с Path. Пришлось везде делать open(str(path))

ээ

а можно теперь на пальцах суть?..

Да, я тоже было предположил поначалу, что вся stdlib возьмет и будет работать с Path. Пришлось везде делать open(str(path))

Это != 'Path будет наследовать str' И вообще было бы неплохо, если бы stdlib принимал path, но уж точно не через наследование

Это != 'Path будет наследовать str' И вообще было бы неплохо, если бы stdlib принимал path, но уж точно не через наследование

но на данный момент это вроде бы простейший способ решить проблему

Это != 'Path будет наследовать str' И вообще было бы неплохо, если бы stdlib принимал path, но уж точно не через наследование

Ну там выше дали ссылку, достаточно.

Я вот с этой ссылкой как раз и соглашаюсь