> Насчёт стримов, если я правильно понимаю сутьНу что значит "если правильно понимаю суть". Вот определение: https://en.wikipedia.org/wiki/Stream_(abstract_data_type)
Номинально -- это тип, для которого должны быть определены: конструктор (привет, кэп!), функция взятия следующего элемента, nil-чекер (опционально, это зависит от реализации).
Может предоставлять конструкторы с разных типов данных, может предоставлять итераторы, редукторы и фильтры -- всё, естественно, строится на основе выше перечисленных функций.
Вот например как это реализовано в OCaml: https://v2.ocaml.org/releases/4.04/htmlman/libref/Stream.html
Или вот как это определено в Haskell: https://hackage.haskell.org/package/Stream-0.4.7.2/docs/Data...
Вот как это реализовано в Scala: https://www.scala-lang.org/api/2.12.7/scala/collection/immut...
В Java: https://docs.oracle.com/javase/8/docs/api/java/util/stream/S...
В Racket: https://docs.racket-lang.org/reference/streams.html
Вот где это в Python? Я последний раз искал в 2017-м, так и не нашёл. Yield-ить, это конечно здорово. С yield-ом я безусловно могу собственную абстракцию стрима сделать. Но почему за 30 с лишним лет нет готовой?
> Не знаком с проблемами copytree, но, описанное поведение звучит логично и ожидаемо, я всецело его приветствую
Ну так я Вам поясню, почему это не логично и не ожидаемо. Вы при копировании дерева создаёте *новые* файлы и директории. Вполне логично и ожидаемо то, что эти новые файлы и директории должны иметь новые stat-ы, в которых будет содержаться время их создания. Вы спрашиваете почему?
Ну например потому, что так оно предполагается на уровне glibc и ядра: https://pubs.opengroup.org/onlinepubs/9699919799/functions/o...
Я ведь про сисколлы вспомнил не потому, что их надо экономить, а потому что при создании файлов согласно спецификации должны быть выставлены актуальные ctime/atime/mtime, и это прямым текстом написано по ссылке выше (прошу, проверяйте). Именно это я подчёркиваю, когда напоминаю, что смена stat-ов -- это *отдельный* сисколл.
Или например потому, что прочие инструменты, с которыми мы работаем каждый день, например тот же cp из комплекта coreutils -- по умолчанию при рекурсивном копировании директории stat-ы не копирует.
Ну или например потому, что системы автоматической сборки пакетов (deb/rpm) зачастую определяют список файлов просто проверяя destdir на предмет появления в нём новых файлов посредством поиска по времени. И эта логика гарантировано ломается, если какой-нибудь умник использует дефолтный copytree в install-скрипте.
Надеюсь, этих аргументов достаточно?
> В угловых случаях, манки-патчинг никто не отменял.
Да, конечно. Ничто не мешает взять дефиницию copytree и переписать под свои нужды. Или просто использовать os.system("cp -R <...>"), кстати. Но всё-таки если тебе приходится прибегать к манки-патчингу библиотеки, это плохо говорит о библиотеке. А что это кстати за библиотека, в которой находится модуль shutil? Ну надо же какие дела, это The Python Standard Library.
> Нужно понимать, однако, если добавить РЕДКИЕ случаи в стандартную библиотеку, это ощутимо замедлит код в обычных частых случаях.
Да в том-то и дело, что случай не редкий. Я согласен, что в *стандартную* библиотеку нужно добавлять часто используемые строительные кирпичики, из которых можно что-либо построить интуитивным образом. И copytree как раз идёт этому видению наперекор.
В заключение, что тут хотелось бы отметить, так это то, что всё выше перечисленное -- это только верхушка айсберга. Мне довелось плотно поработать с Python где-то в 2017м, и я находил подобных косяков тогда пачки. Описанное мною выше это лишь то, что я удосужился записать, чтобы не забылось. А всего остального я просто уже не вспомню, поскольку поставил крест на Python, и по возможности стараюсь с ним лишний раз не связываться.
