А что никто не пишет про релиз Python'а версии 3.11?

Без паники, товарищ! Все выкинутое запихнут в модуль old_standart, чтобы подключать одной строкой.

Положено начало урезанию стандартной библиотеки. Пока что половину только заdeprecate’или,

Половину? Задепрекейтили несколько модулей, большинство из которых устарели уже лет на 20 (типа sunau).

Ни одного модуля из списка я за все свои 22+ года использования Python, не использовал. Разве что была необходимость в msilib для одного рабочего проекта, но в итоге заюзать его не удалось, т.к. он платформозависимый и работает только на Win32, а мне эта функциональность нужна была в кросс-платформенном приложении.

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

А его как раз таки и начнёт колбасить

А потом всё внезапно развалится

Этому пророку больше не наливать.

Да, ну. Это всё притянуто за ушли. Самое главное - скорость Python растёт! Хейтеры утирают слёзы.

А что никто не пишет про релиз Python'а версии 3.11?

Тебя ждали.

Удаляют-то всякий мусор, например я теми модулями ни разу не пользовался, сомневаюсь что кто-то из присутствующих пользовался:
https://docs.python.org/3.11/whatsnew/3.11.html#deprecated

Удаляют-то всякий мусор

А как же, например, pipes?

А как же, например, pipes?

До сегодняшнего дня не знал о его существовании, хотя пишу на Python где-то года с 99-го.

Работал в самых разных проектах: маленьких, больших, хобби. Ни разу этот модуль мне не понадобился, ни разу не встречал его в проекте никакого масштаба.

Судя по всему, у разработчиков Python такая же статистика.

Да и применимость его вызывает сомнения… Мне задачи, которые он решает, ни разу не приходилось решать в Python именно таким образом. Возможно, потому что я о нем не знал… Но сомневаюсь, скорее, дело в том, что он на самом деле бесполезен.

22+ года использования Python

Пользуясь случаем поинтересуюсь: табы или пробелы?

PEP-8 давно поставил точку в этом споре.

Пайпы же часть юниксвея. При написании скриптов на bash'е они сплошь и рядом.

Понятное дело, что можно, например, писать в файл из одного процесса, а потом читать тот файл другим процессом, но в том и задумка пайпов, чтобы передавать данные без записи в файлы. Так быстрее.

ЗЫ. Вчера не мог нагуглить чем предлагается заменять pipes. Теперь же увидел, что в качестве альтернативы предлагается subprocess.

ЗЫ2, Да, есть ещё os.system(), но это не вариант если надо передать данные из какого-нибудь массива.

что в качестве альтернативы предлагается subprocess

Что логично, потому что pipes - надстройка над /bin/sh.

Пайпы же часть юниксвея. При написании скриптов на bash’е они сплошь и рядом.

Питон то тут причём? На уровне ЯП принято уже оперировать не пайпами, а пайплайнами - конвейерами более высокого уровня.

Питон то тут причём? На уровне ЯП принято уже оперировать не пайпами, а пайплайнами - конвейерами более высокого уровня.

Допустим, в pipes так всё и работало. Тут вопрос в другом. Если программисту даже пайплайны не нужны, то возникает подозрение, что он всё делает через файлы, а о пайпах даже не задумывается.

Хотел то же самое написать, но уже ответили. В Python обычно не нужны шелловские пайпы, в нём пишут другие пайплайны на генераторах и itertools. Такие пайплайны приходится писать регулярно, а вот, чтобы мне надо было из питона дёргать шелловские пайплайны - вообще ни разу не было нужно.

пайплайны не нужны, то возникает подозрение, что он всё делает через файлы, а о пайпах даже не задумывается.

Да в Python есть пайплайны, только другие, более удобные. Этот модуль pipes в них нужен, как рыбке зонтик. Как раз с ним код будет непонятным, неудобным, и непереносимым (т.к. завязан строго на Unix shell).

Т.е., по сути, переизобретаются велосипеды, но с усовершенствованиями? Ясно, понятно.

Изменений дофига, однако. Интересно как они скорость подкрутили. Чую обновляться будет больно.

Блин, да какие велосипеды. Ты на Python вообще пишешь? Эти пайпы нужны в shell’е, нахера тащить их в Python, где они совершенно не к месту, инородны.

Ты вот сможешь найти аналог такого модуля в C++, Java, Haskell, go, Rust? Думаю, что нет, потому что в любом высокоуровневом языке такие задачи решаются своими средствами, нативными для языка, а не запуском процесса с bash.

Здесь про скорость очень понятный пример: https://realpython.com/python311-new-features/

Для меня скриптовые языки из ряда Perl, Ruby, Python,... etc являются более мощными заменителями bash'а. Ибо скриптовые. А скрипты для того и существуют, чтобы связывать бинарники и выполнять интерактивную работу (для чего в своё время придумали Focal).

А то, что и склеивается скриптами, пишется на компилируемых языках: C/C++, Pascal, Fortran,... etc

В C/C++ и Паскале есть popen().

В C/C++ и Паскале есть popen().

В питоне тоже.

Короче, я не понимаю, зачем спорить о том, чего не знаешь?..

Я так понимаю, опыта написания хотя бы двух строк на Python нет, глаз зацепился за pipes, и захотелось развести спор, типа, раз удаляют модуль с таким названием, значит из языка удаляют все возможности создавать пайплайны. Ужас, кошмар, эти страшные люди питонисты, отвращают от своего языка любителей bash!

Увы, сенсации не выйдет, и не вижу смысла продолжать сей бессмысленный спор с человеком, который вообще не понимает, о чем рассуждает и спорит скорее с голосами в своей голове.

глаз зацепился за pipes, и захотелось развести спор

Нет. Я писал на Python'е. И другого способа вывести данные в пайп кроме pipes не находил. Не находил и всё тут. Гугл мне конкретно про pipes информацию возвращал. Хоть я и находил его ограниченным.

Я тут как-то вскользь упоминал про ограниченность пайпов в Python'е. Говорил, что напишу потом как при помощи моей утилиты можно обойти эту ограниченность. Мол, так-то можно только юникод софтине по пайпу передать, а при помощи моей утилиты можно и бинарные данные. Говорил, что потом подробнее напишу, но так пока и не написал. Так вот, под «ограниченностью пайпов» я подразумевал конкретно ограниченность pipes.

Я даже исходники реализации pipes читал, чтобы понять действительно ли всё так ограничено.

И это хорошо если есть и другие варианты, я только за.

pipe - это просто файловый дескриптор. Передавать данные между файловыми дескрипторами в Python можно кучей различных способов.

Мол, так-то можно только юникод софтине по пайпу передать, а при помощи моей утилиты можно и бинарные данные.

Что-то ничего не понимаю. Нет вообще никаких проблем, мы просто пишем в файловый дескриптор байты. Unix не пытается интерпретировать байты, которые пишутся в файловый дескриптор. Python на Unix/Linux также не пытается своевольничать.

Либо нужно видеть исходник, либо я просто не понимаю по такому описанию, в чём проблема.

И для этого pipes вообще не нужен: просто запускаем софтину при помощи одного из методов модуля subprocess, и пишем ей в stdin.

Нет вообще никаких проблем, мы просто пишем в файловый дескриптор байты.

Это хорошо если так можно. Я говорю конкретно про библиотеку pipes, поскольку ничего другого для работы с пайпами в Python'е я до сих пор не находил. Такой вот у меня поломанный Гугл. Документацию тоже открывал, но, видимо, криво читал. Так вот, эта pipes передаёт конкретно текст, а текст в Python'е конкретно UTF-8. И если пытаться передавать ей произвольные байты, то вылазит ошибка типов данных. Видимо, поэтому и выпиливают. Тем более если есть и другие варианты в стандартной библиотеке.

• NodeJS не развалилась.
• Go не развалился.
• Rust не развалился.

И Python не развалится.

раньше было джве одинаковых, но несовместимых мажорных версии пипона, а теперь будет одна несовместимая в кажном миноре?

Я говорю конкретно про библиотеку pipes, поскольку ничего другого для работы с пайпами в Python’е я до сих пор не находил.

https://docs.python.org/3.11/library/subprocess.html#replacing-shell-pipeline

текст в Python’е конкретно UTF-8. И если пытаться передавать ей произвольные байты, то вылазит ошибка типов данных.

Нет, в Python есть тип str, который хранит текст Unicode. Не UTF-8, т.к. UTF-8 — это конкретное байтовое представление. Внутри для этого используется UCS-4, кажется, но это неважно, т.к. деталь реализации.

И есть тип bytes, который просто набор байтов, которые интерпретатор не пытается никак интерпретировать.

str можно преобразовать в bytes, указав при этом, какую кодировку необходимо использовать для преобразования unicode-текста в байтовое представление. Например, utf-8. И наоборот: bytes можно преобразовать в str, указав при этом кодировку, в которой записан побайтово текст.

Без хорошего понимания этих вещей невозможно написать ни один скрипт на Python, который будет читать или писать текст на экран или в файлы.

Я не знаю: возможно в pipes был какой-то баг с str/bytes, но учитывая, что за всё время, что я работаю с Python, такого не было, думаю, что ошибка была всё-таки не в pipes.

3.11

For Workgroups?

For Workgroups?

Можно устроить перепись тех, кто родился ещё в прошлом веке.

тех, кто родился ещё в прошлом веке

Таких, наверное, большинство. Кмк, ЛОР - возрастной.

For Workgroups?

Это скорее про тех, кто разменял или через пару лет разменяет полвека.

Нет, в Python есть тип str, который хранит текст Unicode. Не UTF-8

В любом случае пишем, например:

mypipe = pipes.Template()
mypipe.append('myprog', '--')
with mypipe.open('pipefile', 'w') as pfptr:
    pfptr.write(myblob)

TypeError: write() argument must be str, not bytearray

И как часто ты используешь pipes?

Хотел возмутиться, попробовал, и ты прав. Этот модуль поддерживает только текстовый ввод-вывод, и под капотом у него тоже os.popen(), который не поддерживает бинарный ввод-вывод.

Так что, прошу прощения, я с самого начала был неправ.

Тем больше причин выбросить этот модуль. Мне непонятно его назначение. Всё, что он делает, можно сделать через subprocess с большим контролем над происходящим. Это помимо того, что мне вообще сложно представить, зачем нужно строить bash’евские пайплайны в Python строго таким образом, каким это делает bash.

На FreeBSD:

Прописал /etc/make.conf дефолтную версию python311.

Собрал из порта lang/python311.

Удалил установленные пакеты предыдущей версии py310-*.

Пересобрал все зависимые от python310 пакеты из портов portmaster -gDr python310.

Осталось libreoffice дождаться, когда будет поддержка.

Но, зачем?

Всё равно придётся.

И как часто ты используешь pipes?

Иногда. Теперь буду переходить на subprocess.

Можно пруфы? Теперь он не в 170 раз медленнеей Си а в 169, да?

медленнеей Си

почему сравнение не с Ассемблером, например?

Орнул :) Как заметили выше, действительно, а чего сразу не с ассемблером сравнивать?

Не только.

По простой причине, что это хороший референс для сравнения.
Шарп медленней Си в 3 раза, Жаба в 4, Похапе в 12, Пистон в 170.
Понимаешь, да?

ASM не подходит, ибо реализация даже простых бенчмарк алогиртмов слишком платформозависима.

Орал я, когда в Blender obj импортер, написаный на Пистоне, переписали на Плюсах и полуторачасовый импорт сократился до 50 секунд.

Для сборки firefox и thunderbird всё ещё нужен python310 или 3.9.

Для сборки firefox и thunderbird всё ещё нужен python310 или 3.9.

Может в следующей версии завезут.

Это нормально, когда какие-то узкие места - можно ускорять более низкоуровневым кодом.

Реальность такова, что на Пистоне вообще нельзя писать хоть что-то связанное с расчетами. Только клеящую логику...
В Blender кстати в гайдлайнах прямым текстом теперь написано, что Пистоном трансформировать геометрию запрещено.

Шарп медленней Си в 3 раза, Жаба в 4, Похапе в 12, Пистон в 170.

Откуда данные?