PyMGet - параллельное скачивание файлов с нескольких зеркал

NETDTHC
Я тебе ещё более конкретную ситуцию привожу. Не абстрактное «качать раз в месяц», а конкретно: возникла необходимость посмотреть содержимое файла в Минте. Можно выяснить через 2 минуты, можно через 10 минут. Что лучше?

Ну, конечно, через 2 лучше. Но нет особенной разницы в данном случае. Оно ж не 10 часов качается, и даже не час. Это несущественная разница, на которую можно и внимание не обращать. С современной скоростью интернета многие вещи потеряли смысл вообще..
Мы ж о тривиальных задачах ведь ооворим,а не об администрировании серверов, о которых VVD0 говорит.
А управляя автомобилем, ты тоже стараешься быстрее доехать, или едешь так, как тебе удобно и ненапряжно? Вот и в этом случае точно так же. Лично я не зацикливаюсь на подобных вещах. Меня напрягает, когда в определенные часы или падает скорость (пик активности юзеров) или же некоторые сервера вообще недоступны (идиоты компьютеры выключают). А если берется с нормальной скоростью - то нормально. И неважно, 12 это метров в секунду, или же 5. Все равно, когда докачается, входящий канал вообще простаивать будет. Да и у меня давно уже не бывает такого, чтобы я тупо сидел и ждал, когда оно там скачается. Поставил и забыл. Вспомнил, что нужно глянуть файл - открыл, глянул. А через 10 минут возникла эта необходимость или через 10 месяцев - вообще пофиг.
Другое дело, когда посмотреть надо срочно. Доставили человека, к примеру, и в течение срока задержания его надо "пробить" и от результата будут зависеть дальнейшип действия. Вот тогда да, надо быстро.

8 минут всегда останутся 8 минутами. Это приличное время, если информация нужна прямо сейчас. Ты похоже реально не понял. Необходимость посмотреть возникает не из-за того, что скачал файл, а файл я качаю из-за того, что возникла необходимость посмотреть. Она возникла здесь и сейчас и чем быстрее эта необходимость будет удовлетворена - тем лучше. Я тебе скажу, что даже 2 минуты в этой ситуации - слишком много. Но здесь уже технические препятствия.

Да это я понял. Баба захотела перепихнуться - ты побежишь, бросая все дела, ее удовлетворять? Или ты сначала закончишь свои дела перед этим, если чем-то занимаешься в данный момент? А вспомни, как 15 лет назад 2 гига неделю качали. И какие матюки сыпались, если вдруг оборвется.. А сейчас 2 минуты долго уже.. Нужно просто не думать о том, что что-то качается (компилируется, кодируется) и т. д. Я это пытаюсь тебе объяснить. Но никак не утверждаю, что медленно качать лучше.

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

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

Это высосанный из пальца пример - так никто не пишет.
Даже студентам сразу дают пример с проверкой pFile на NULL следующей строчкой после fopen и они его тиражируют. Проверку на код ошибки можно и не делать в учебных примерах, но в реальном ПО диагностика обязана быть.
По поводу ошибок в ПО на питоне - я с самого начала написал, что не записываю и не сохраняю их, поэтому придумал что-то простое для примера. Не надо мне их разбирать сейчас - это пустая трата времени. Когда в следующий раз столкнусь с реальной ошибкой - твои рассуждения вряд ли помогут, а об этом треде я могу и не вспомнить. Ты задолбаешь нормально это реализовывать на шеле. Получится ещё более глюкаво, чем на питоте. На шеле пишут или не сложные вещи или одноразовые, которые после использования выкидывают.
Мой юзкейс был в другом - файлов много, размеры их разные, перечень зеркал идентичный. Неплохо бы их скачать наиболее быстро, но при этом ресурсов CPU, RAM и HDD надо занимать минимально, так как это всего лишь одна из 100 мелких утилиток на этом хосте, используемая в автоматическом режиме и по расписанию.
NETDTHC
Универсализм должен быть разумным. Твой пример граничит с маразмом, а мой вполне жизненный.

Точно как и try-except в питоне. Ты пойми, что аналогия 100%-я: дело в программистах, а не в языке. Ну раз пока никто не реализовал это на C/C++, то наверно всё проще. Не стоит сгущать краски, решение довольно прозрачное.
Впрочем, какое это имеет отношение к проблеме, поднятой мной в этой теме? Если файлов несколько - это из другой оперы, как я уже сказал.

Не 100%. Без проверки кода ошибки ПО на C может работать корректно, только неинформативные сообщения об ошибках будут. В случае с питоном будет непонятный стектрейс, но не сегфолт. Это способствует забиванию на этот try-excrpt. Реализовано только частично. Хм. Как ты на шеле проверки кодов возврата будешь делать? Вернее не задолбаешься ли? А маскировку всех входящих параметров? Может ты мало на шеле писал, и по этому утверждаешь, что это легко. Вернее так - реализовать чтобы работало на ограниченном множестве входных данных и без внешних нештатных ситуаций действительно просто, но сделать корректно работающую на всех данных при любых условиях практически невозможно. Я с шелом достаточно много ковырялся, поэтому и сужу. for FILE in ${LIST}; do
multiget ${FILE} ${MIRRORS}
done

Абсолютно необоснованное суждение. Как раз «Без проверки кода ошибки ПО на C может работать корректно» точно так способствует забиванию на контроль за ошибками. Да как бы $? - уже есть в моём примере. А насчёт «задолбаюсь» - так не я же буду эти заниматься, а скрипт. А он не задолбается... Я решаю поставленную задачу как она звучит (список файлов, список зеркал - качать параллельно), а не пытаюсь создать универсальный комбайн. Ксттаи, это unix-way в отличе от всяких Nero Я сейчас ещё раз посмотрел multiget. Но это же чисто GUIвая прога. Ты наверно за какой-то другой multiget говоришь, о котором я не знаю?
Да и потом, это всё равно не имеет отношения к поднятой мной проблеме. Моя задача - один файл, один. Неужели это так трудно понять?

Как и всё, нет? Перебор всегда плохо и при этом даже полезные вещи начинают приносить вред..
С примерами и сравнениями мы действительно углубились, но ведь MappingOrgUa предложил решение конкретной задачи. Мне пофиг, что дистрибутив порой качается 10 минут вместо двух, тебя не устраивает питон. Сейчас еще кто-то зайдет и скажет, что дистрибутивы надо через торренты качать и скрипт этот не нужен. : -D

После получения NULL можно просто написать, что не могу открыть файл и выйти, а можно ещё и код ошибки посмотреть. В любом случае это информативней питоновского трейса. Я не об этом. Ты будешь после каждого вызова любой внешней утилитки городить "if с $?"? Именно это ты задолбаешься делать. Скрипт сам себя не напишет. В общем ты какую-то х*ню-с сморозил-с. Зачем ты переводишь разговор в какую-то непонятную сторону? Ты мне предложил реализовать вариант с много файлов на шеле. Я сказал, что качественная реализация совсем не тривиальна и даже показал ряд проблем. Какое отношение тови слова имеют к моему тезису? Это псевдокод того, как твоей утилиткой можно скачать много файлов. Никакого отношения к тому multiget-у не имеет.
Вот так понятней?

Стоп, стоп, стоп. Получив NULL можно что угодно написать - согласен. Но и получив исключение в блоке except можно написать то же самое слово в слово. В обоих случаях это зависит исключительно от программиста. разница в языках лишь в реакции на необработанные ошибки: C\C++ вываливается в неинформативный сегфолт, питон же выдаёт довольно подробный трейс. Просто ты сравниваешь правльно написанную программу на C с неправильно написанной на питоне. В само условие эксперимента закладываешь желаемый ответ. Зачем? Ну если я говорю про одну единственную утилиту - wget и вызываю её в цикле, т.е. в скрипте эта строка встречается один раз, - в чём гемор? Тебе нужны шашечки или ехать? Ну то есть тебе нужно файлы скачать или получить универсальную программу на все случаи жизни. Вот что я имею в виду. Ах, вот оно что.. Но это забивание гвоздей микроскопом. Если файлов много - нет нужды разрезать их и тянуть по-частям. Опять же: незачем устанавливать по одному соединению с каждым зеркалом для каждого файла. Достотачно соединения с одним зеркалом для каждого файла, суммарно их всё равно будет много и скорость будет высокой. Ты пытаешься применить программу там, для чего она в принципе не предназначена.
UPD:
В общем, как-то так на bash выгдлядит скачивание нескольких файлов с нескольких (общих) зеркал: Использование: где FILES - файл со списком файлов, MIRRORS - файл со списком зеркал. Сохраняются файлы в папку distfiles.
Разумеется, совершенству нет предела, и усовершенствовать скрипты можно до посинения. Но основную идею я показал.
UPD2: Кстати, я только сейчас обратил внимание. Твой скрипт не запустит скачивание параллельно. Все файлы будут качаться по-очереди, т.к. дойдя до вызова pymget скрипт остановит свою работу и будет ждать завершения скачивания файла. Причём сильно мелкие файлы (меньше размера блока pymget, который по-умолчанию равен 4MB) будут качаться вообще с одного зеркала (сильное уменьшение размера блока увеличивает накладные расходы на запросы к серверам, так что профит сомнителен). В итоге ты ничего не выиграешь, разве что твои файлы хотя бы по несколько десятков МБ.