С 14 декабря перестал работать поиск ("pip search") в репозитории Python-пакетов PIP. Причиной является большой поток запросов XMLRPC, негативно влияющих на инфраструктуру...Подробнее: https://www.opennet.me/opennews/art.shtml?num=54335
Надо было просто переписать на си.
Спроси у Фроктала.
Он сишные дырени на дорогах россии латает
Видимо делает это так же как програмит все на хрусте.
Вот когда добавят в него здоровые элементы ооп - тогда возможно
ООП дрочер?
В Си нет struct? Чего тебе ещё ООП-специфичного сильно не хватает?
В struct нет нормальной икапсуляции для методов. Нет наследования вообще.
Наследование заменяется композицией в большинстве случаев без каких-либо проблем.
Нормальной инкапсуляции нет, но в масштабе небольших Си программ это не трагедия.
В общем жить можно и без сахара. Просто не так сладко.
Проблема сладкоежек, сугубо их проблема. Почему отсутствие ООП - совершенно другой парадигмы должно считаться каким-то недостатком? Структурная парадигда полностью самодостаточна.
А зачем тогда мучаться, если есть C++?
Да 100500 причин: от "тут так принято" и "потому что 99% проекта уже написано на Си" до "не знаю я никаких ваших плюсов, деды писали на Си, вот и я пишу на Си"
Томпсон терпел и нам велел!
Наследование делается через member field.Инкапсуляция для методов обычно не нужна, но если очень хочется, добавь поле указателей на функции, которым разрешено работать с этой структурой. Получишь даже круче, сможешь туда добавлять и удалять функции по требованию.
Полиморфизм делается через union.
Наследование классов - зло. Нормальным является только наследование интерфейсов
Множественное наследование - зло, линейное - естественно.
> Множественное наследование - зло, линейное - естественно.Гораздо прикольнее когда кто-нибудь оверрайд операторов сделает. После этого любой obfuscated C code contest отдохнет - код, вроде, как на ладони но делать может ну вот вообще совсем не то что вы там себе вообразили.
> В struct нет нормальной икапсуляции для методов.Указатель на функцию тебе в рожу, гомоморфный.
И что? Это, всё равно, приводит к реализации этих функций с длинными глобальными именами, чтобы те указатели ими проинициализировать. И ручками передавать указатель на экземпляр самой стоуктуры, вместо того, чтобы это делал компилятор.
> И что? Это, всё равно, приводит к реализации этих функций с длинными
> глобальными именами, чтобы те указатели ими проинициализировать.Имена будут ровно такие как напишешь.
> И ручками передавать указатель на экземпляр самой стоуктуры, вместо того, чтобы это делал компилятор.
Кто ж это ручками указатели то прописывает, кроме очень сильно некоторых случаев? Так то их тоже компилятор заполнит.
Более того - с указателями то на функцию можно и чего поинтереснее, типа "динамического импорта" из вон той либы (и вообще куска кода). А попробуй так с твоим си++, расскажешь как получилось.
Я же сказал _нормальной_, а не костыльной.
> Я же сказал _нормальной_, а не костыльной.Ну, э, получается что все .so'шки/DLL-ы, особенно с импортируемыми в рантайме функциями - костыль? Вы не слишком там расшумелись, вебабизянки?
Фу на Питоне кодить.
Да ну, они на каждый запрос базу теребят, что ли?
+ еще сформировать и распарсить xml это же легко. питонист это не про эффективность
Это точно!Периодически поглядываю Trac у проекта 0.A.D, и он также периодически вываливается в Service Unavailable.
Питон всё-таки неторопливая змея и прожорливая :)
Питон настолько медленный что numpy перемножает матрицы в десятки раз быстрее, чем самодельная либа с алгоритмом из школьного учебника.
вот бы numpy на питоне был написан.
какая разница, на чем он написан, если в профессиональной питон-разработке он применяется повсеместно, и альтернатив ему на других языках крайне мало
> профессиональной питон-разработке
> профессиональной
> питон-разработке
> профессиональнойСпасибо, ты сделал мой день.
во время следующего перерыва в ковырянии баш-портянок своего локалхоста, погугли, на чем и кем сделаны 90% ml-фреймворков
да че вы там носитесь со своими ML? Пихон там используется просто как очень мощный... конфигурационный файл (sic!) нейросеток. Типа как ini, но с переменными. Причем в тензорфлове пихон для Lambda нужно писать особым образом, чтобы его можно было скомпилить в какой-то свой собственный байткод, а не в пихоновский.Далее, касательно нумпи. Используется учеными, да. Не программистами, а учеными, которые используют пихон как очень мощный калькулятор (sic!), а не язык программирования. Потому что язык программирования нужно сидеть и учить, а пихон особого изучения не требует -- нумпи в руки и вперед, рисовать в matplotlib всякую невоспроизводимую в будущем хрень.
Ну и, как вишенка на торте --
https://github.com/tensorflow/tensorflow
C++ 61.2% | Python 26.2%
Более того - появилась куча всяких TF Lite и проч, которым питон не уперся. А потому что гадюка которая не тормозит и ломается раз в пару месяц устраивает только ученых, разбирающих свой макет через месяц. А если он все же в продакшне остается - ну вон гугол в go вдарился, и не только он.
Он сделан модулем для питона, а значит переписать его на Си не составит труда.
Только кретину (иксперту опеннет) может прийти мысль, переписывать модуль, структуры данных которого оптимизированны для взаимодействия с cpython, переписывать для работы с интерпретаторами других яп
> какая разница, на чем он написан, если в профессиональной питон-разработке он применяется
> повсеместно, и альтернатив ему на других языках крайне малоразница в том, что кто то тут пытался сказать что numpy такой быстрый потому что питон. а это мягко говоря не так.
Потому-что речь шла про скорость Python'а и вы привели в пример быстрый numpy, который на C/Fortran.
В том-же Android'е Dalvik /ART? Ага, только вот как только разработчикам дали NDK все что можно стали переписывать нативно и в итоге в пакетах N so'шек лишних -_-"
Дай угадаю. Самоделкин при самоделании не подумал почитать документацию и узнать про какие-то другие типы данных в стандартной библиотеке? dict/list таки ваше все?
Numpy по сравнению с tensorflow для cpu сосёт.
> Питон настолько медленный что numpy перемножает матрицы в десятки раз быстрее, чем
> самодельная либа с алгоритмом из школьного учебника.Проблема в том что то что умножает матрицы быстрее - внезапно не на питоне, бидабида :)
Мне, как конечному программисту, пишущему прикладухи, вообще без разницы на чём там написан ы потроха этого numpy. Хоть на яваскрипте, мне плевать. Утрированно, у меня задача - перемножить матрицы, надо сделать это быстро. И мне написать на питоне это перемножение гораздо быстрее получится и оно будет быстрее выполняться, чем если я буду писать на Си.
А на что именно поглядываете, если не секрет? Я там переводчиком помогаю, а вы?
А я поглядываю просто на текущий статус заявок, ожидая 24-й альфы. Исключительно с потребительской точки зрения поглядываю :)
Если есть желание (и у вас не Zen 2), можно сбилдить самому то, что есть на текущий момент. Никаких кардинальных изменений больше не будет в рамках 24 версии, основная причина задержки -- несовместимость с Zen 2, которую обязательно нужно править.
>Питон всё-таки неторопливая змея и прожорливая :)Адаптировать программу под PyPy.
> Адаптировать программу под PyPy.Java: write once, eats RAM everywhere.
Python: write once, rewrite forever.
Причем тут питон? Такие проблемы возникают из-за неправильной архитектуры, технологии тут не играют никакой роли. Инстаграм вон, например, на питоне прекрасно себя чувствует.
Просто питонисты любят pure python батарейки пихать везде, а это же дно по производительности. Сложно объяснить почему бы не выбрать нативные вместо этого. Например, тот же pycurl и больше возможностей имеет и в миллион раз быстрее requests, Но, это же не так "красиво" в коде будет, и видимо это единственная причина (пока тебе не придётся заниматься манки патчингом вместо того чтобы взять опять же pycurl).
Да причем тут вообще конкретные технологии? Ты хоть на питоне напиши с самыми быстрыми либами, хоть на си, хоть на асемблере, рано или поздно ты упрешься в производительность одного сервера и тебе придется горизонтально масштабироваться. А невозможность горизонтально масштабироваться это архитектурная проблема.
Зачем в данном случае горизонтально маштабироваться? Купить новый ДЦ под никем невостребованный функционал вместо того чтобы отскалировать в разумных пределах? Ну и чем проще масштабировать, тем выше накладные расходы, на каких-то направлениях серьёзные нагрузки могут просто быть не предусмотрены сознательно.
Если питон в 20 раз медленнее - то это "рано или поздно" настанет рано. И если для питона это год, то для С - аж 20 лет, за которые либо ишак либо эмир сдохнет."Рано или поздно", хех.
Только пока ты на си это будешь писать, проект на питоне запустится, накупит копеечного железа, закроет несколько раундов инвестиций, а может уже и сам закроется, лол
> Только пока ты на си это будешь писать, проект на питоне запустится,Местные уже десяток лет ноют какой "этот ваш питон" отстой, зачем его пихают в пользовательское окружение, как он (вместе с питонистами совсем-совсе не нужен), потому что есть божественная сишечка ... но дальше нытья и словесных описаний крутых альтернатив "как нужно правильно" дело так и не зашло.
А давайте будем объективными? У Python есть проблемы, как и у C\C++, как и у Rust, как и у любого другого языка. Просто язык надо под задачу выбирать.
> А давайте будем объективными? У Python есть проблемы, как и у C\C++,Ну давайте - при каждом втором упоминании питона вылезают местные знатоки и начинают срач, смысл которого сводится к тому, что питон не нужен, потому что можно и нужно переписать на сишечке, максимум с вкраплениями шелла.
Попутно выливают поток помоев на "бидон" и "бидонистов", нахваливают себя любимых (какждый второй опеннетчик в таких темах - профессиональный сишник с 30 летним стажем).Но дальше балабольства и общих разглагольствований (конкретики местные старательно избегают, потому что частенько вылезает незнание матчасти и элементарных вещей )) дело еще ни разу не заходило - никто еще не запостил "смотрите, я тут переписал мезон!" или "вот с-youtube-dl!".
> никто еще не запостил "смотрите, я тут переписал мезон!" или "вот с-youtube-dl!".Как никто не запостил? Вот был пихоновский createrepo. Переписали на createrepo_c. Такова судьба-судьбинушка пихоновских проектов. На line-by-line-интерпретаторе (QBASIC-style, лол) далеко не уедешь.
>> никто еще не запостил "смотрите, я тут переписал мезон!" или "вот с-youtube-dl!".
> Как никто не запостил? Вот был пихоновский ненужно_. Переписали на ненужно_c.
> А youtube-dl, Meson и еще 100500 юзерспейсных программ даже не трогали.
> Такова судьба-судьбинушка опеннетных критегов.От оно че.
> На line-by-line-интерпретаторе (QBASIC-style, лол) далеко не уедешь.
>>> import dis
>>> def znatoki(x):... return x*x
...
>>> dis.dis(znatoki)2 0 LOAD_FAST 0 (x)
2 LOAD_FAST 0 (x)
4 BINARY_MULTIPLY
6 RETURN_VALUE
Ох уж эти "знатоки" опеннета, прям лол, кек, чебурек.
Вполне неплохая сказка, да.
> Да причем тут вообще конкретные технологии?Притом, что у местных упоминание питона вызывает экзотермическую реакцию под 1500 миллирастов - свербит в одной точке, хочется хоть что-то вбросить.
Сперва задумался, кто такие миллирасты и за что ты их так; но потом даже восхитился.
> миллирастовКрасиво. Но с Питоном занятно - вокруг него сформировалось довольно дикое сообщество, которое пихает этот неплохой язык в совершенно неподходящие для него ниши и плюёт на пользователей.
Это "дикое сообщество" есть в любом языке. *смотрит на раставиков и js-ников*
> Это "дикое сообщество" есть в любом языке. *смотрит на раставиков и js-ников*Ну в rust есть хотя бы достаточно высокая вероятность увидеть ошибку компиляции если upstream поломали. Хотя они какие-то гиперактивные последние годы.
>Сложно объяснить почему бы не выбрать нативные вместо этого.Почему же, очень даже легко. Нативные - этш перекомпиляция всех либ при каждом обновлении дистра. Перекомпиляцию должен брать на себя дистр в идеале, а в реале в пакетах дистра во-первых говно мамонта, а во-вторых зачастую они вообще бывают нерабочими, потому что всем мейнтейнерам по***.
Откройте для себя venv с pip. Зачем так страдать?
AUR и Pacman, не? Если нужен bleed-edge, то рач - идеальный варинат и страдать не надо с пересборкой в ручную каждый раз.
Наркоманией не страдаю. В системе должны быть только интерпретаторы из пакетов.
упаси бох любой любой проект от одминья вроде тебя
На самом деле, у разработчиков на питоне причин для такой "любви" более чем достаточно.Во-первых, чистый питон без танцев с бубном работает на разных платформах, а с этим проблем хватает. Я помню сколько у меня и моих коллег, было проблем с lxml, которая как раз бинарная, и которую надо было под используемую платформу компилить, и помню как мы с удивлением увидели, что у нового решения на чистом питоне мало того, что этих проблем нет, так еще и производительность выше... гм... или по-крайней мере, не ниже. Это как пример.
Во-вторых, код написанный на чистом питоне почти с нулевой вероятностью будет подвержен гонке за ресурсами, а сборка мусора будет работать куда более эффективно, поскольку будет привязана к бизнес-логике приклада, а не к логике бинарной либы.
Ну, и наконец, такое еще соображение (к requests оно, правда, не относится): кооперативная многозадачность в сетевых приложениях в целом более эффективна, чем вытесняющая многозадачность бинарных библиотек, поэтому сетевые приложения на чистом питоне, опять же в целом, работают быстрее, а нагрузку могут взять на себя большую, чем если бы под капотом была бинарная библиотека. Разумеется, тут все очень не просто и бывают разные случаи, но _в целом_ если делать ставку, при разработке сетевого приклада, на бинарь или на скрипт, то лично я в первую очередь смотрел бы на скрипт.
Не знаю. У меня помню было пару раз развлечение собрать lxml для венды, там нужен msvc компилятор и мс предоставляла интеграцию только с 2 питоном (это было с год назад). Или можно было взять любое из десятка окружение с cygwin и не иметь проблем. А дальше pip сам всё скомпилирует и установит.Зато код написанный на чистом питоне утыкается в GIL примерно сразу. Опять же нужны какие-нибудь гринлеты и какой-нибудь uvloop… Который тоже на си, ой. Pycurl например кстати умеет в многозадачность и сам по себе, и освобождает ресурсы питону для более интересных змеиных дел.
> код написанный на чистом питоне утыкается в GIL примерно сразу.ну-ка, ну-ка, прокажи-ка свой код, который уперся в gil примерно сразу, трепло
Изи, пишешь скрапер без нативных батареек и пытаешься выжать локальные ресурсы. С этим каждый справится. Без кучи процессов, только треды. Ты упрёшься в гил уже на 2 тредах.>трепло
Сама такая.
из серии "заставь дурака богу молиться" - для скраппинга как раз гринлеты подходят идеально, зачем потоки использовать там, где им не место?
Да в общем-то не обязательно и скрапер (т.е. разбор xml и сеть) хватит и одного requests или hyper.
ну-ка, ну-ка, рассказывай, как же упереться в gil на одном requests
> ну-ка, ну-ка, рассказывай, как же упереться в gil на одном requestsПросто используй его из двух и более тредов, а потом сравни производительность с pycurl (даже без ухищрений, на которые тот вполне сопособен). И давай это, тон попроще.
Если отстанутся сомнения, прогони под профайлером.
> а потом сравни производительностьво-первых, ты вообще понимаешь, для чего нужен gil, и что значит "упереться" в него? причем тут производительность? во-вторых, есть куча pure python альтернатив requests, если не устраивает производительность, я не удивлюсь, если ты даже итератором не пользуешься, а загоняешь все в память сразу
Почитал я ваши бредни и вот что хочу сказать. Когда у вас будут модельки гигабайтов этак 10 (для начала), вот тогда-то вы и сможете ощущать отсутствие нормальной разделяемой памяти промеж процессами, gil, и прочие прелести питона. Кое-кто эти прелести обруливает на cython, там можно извернуться мимо gil, но это уже изврат с секасом и бубнами.А всякие там requests - про это в детских садиках рассказывайте
бредни - это к разговору о gil приплести разделяемую память, придумать несуществующую проблему и приплести вообще не в тему cython. очевидно, что ты понятия не имеешь ни о прелестях питона, о которых ты, видимо, только читал тут комментариях таких же "икспертов", как ты сам, ни что такое gil, для чего он нужен
Это не важно, из-за GIL питон совершенно однопоточный. Выход из этой однопоточности либо несколько процессов (но тогда ещё больше ресурсов уходит на синхронизацию, а процессы на венде вообще отдельная песня), либо нативные батарейки.
> Это не важнов принципе, на этом с такими как ты любые дискуссии нужно заканчивать, желательно увольнением
> из-за GIL питон совершенно однопоточный
повторяю, ты совершенно не понимаешь, что такое gil и для чего он был сделан. из-за gil нет возможности эффективно освобождать ресурсы в случае сильного расхождения времени исполенния в потоках - ВСЕ! это единственный и да, немалый минус, но в итоге в питоне безопасный, простой (а значит быстрый) механизм работы с потоками, в том числе вызывающими функции нативных модулей
Я не понимаю? А может быть ты поленился проверить под профайлером, сколько ресурсов уходит на синхронизацию тредов и конкретно на него? Ты же самый умный, да?>в том числе вызывающими функции нативных модулей
Нативные модули его освобождают когда только могут, быстрые они не в последнюю очередь по этой причине.
Я не питонист, но как пример: передача одновременно данных от множества криентов к серверу и обратно с некоторой обработкой.На c/c++/go это реализуется просто, упираемся лишь в канал.
Написание серьёзных программ на Питоне - это отличные вложения в job security. ;-) Что-то подправлять придётся практически ежегодно.
> Написание серьёзных программ на Питоне - это отличные вложения в job security.
> ;-) Что-то подправлять придётся практически ежегодно.В активном проекте код приходится править постоянно.
Причем, куда чаще приходится что-то подправлять по инициативе бизнеса, нежели из-за того, что обнаружен баг. Я бы оценил, что соотношение где-то 1/20 - на каждую правку найденного _бага в продуктиве_, приходится не менее двадцати, а то и более, новых достаточно крупных фичей от бизнеса.
В сущности, процесс развития кодовой базы носит непрерывный характер. И такое положение дел всех, - включая и бизнес, кстати, - вполне устраивает.
И между прочим, я не думаю, что в этом смысле, проекты на питоне чем-то принципиально отличаются от проектов на других ЯП. В конце-концов аджайл, он для всех, а не только для питона.
> В активном проекте код приходится править постоянно.Ну и зачем себе жизнь усложнять, добавляя правки из-за поломок совместимости upstream?
> В конце-концов аджайл, он для всех, а не только для питона.
Слава богу, не везде аджайл, есть и нормальные места.
> ;-) Что-то подправлять придётся практически ежегодно.Ежемесячно не хотели?! А потом можно еще затеять отдельный проект, лет на 5 - на го какой-нибудь переписать.
>кооперативная многозадачность в сетевых приложениях в целом более эффективна, чем вытесняющая многозадачность бинарных библиотекРазве вытесняющая не включает в себя кооперативную как частный случай?
>>кооперативная многозадачность в сетевых приложениях в целом более эффективна, чем вытесняющая многозадачность бинарных библиотек
> Разве вытесняющая не включает в себя кооперативную как частный случай?Нет, не включает.
Я бы сказал, что кооперативная многозадачность не является частным случаем вытесняющей, а скорее _использует_ механизм вытесняющей многозадачности для собственных целей.
Так, на основе вытесняющей многозадачности, происходит организация событийной петли, а так же и принудительное переключение контекстов тех со-программ, которые слишком много на себя тиков проца берут. Но со-программы все же сами определяют те участки кода, где основной поток может переключить их контекст. То есть планирование процессов происходит в соответствии с бизнес-логикой приклада, что собственно, и дает профит при определенных условиях.
Объясните нубу, зачем использовать requests если есть urllib, который ещё и "батарейки".
Ты имеешь в виду urllib3? Ну можно, но осторожно. На самом деле не очень можно - однажды мейнтейнеры проекта совсем поехали, разом закрыв все PR, потому что у них типа нет времени на их разбор. После этого urllib3 для меня умер.
Коллега, ты прав как никогда. У нас на питоне вполне шустро работают собственные реализации некоторых широко известных в узких кругах алгоритмов. Мы не используем "батарейки". Кстати, насчет них, где-то год назад шеф возмутился - а что это мы какое-то малоизвестное старье для вэбморды используем - а давай переедем на flask. Я чуйкой чуял что говно этот flask, но для убедительности нашел статейку где чувак ясно сказал, что flask == mediocrity. И хрен бы с ним, этим flask-ом. Я пробовал искать современные асинхронные либы/фреймворки - сцка, они все копируют посредственность. Если посредственность не скопировать - потеряют целевую аудиторию. В сонике, кажется, они это открытым текстом прописали. Не питон закапывать надо. Надо закапывать говнокодеров - фанатов популярного говна.P.S. для хозяина этого говносайта: сцка в правильном написании и произношении давным-давно одобрено газпром-медиа, федеральными телеканалами и путиным лично
> Инстаграм вон, например, на питоне прекрасно себя чувствует.А его еще не переписали? А то это ж фэйсбук теперь, а у тех чего только нет, вплоть до трансляторов php в c++
Инстаграмм может позволить себе чувствовать себя прекрасно на чём угодно.А с питом да, дело в неправильной архитектуре, и ничего ты с этим не поделаешь.
В чо такова, сначала весь хмл в память, потом в дом, потом ебануть сверху xpath, достать те два значения, ради которых это всё делалось, и тд. А, ещё на каждом шагу надо синхронно логировать происходящее на диск. А потом отключить поиск потому, что xml тормозит - плохая технология, причина выявлена, фикс наложен. А что касается тормознутости питона, вы видимо в 90-ых застряли - память сейчас дешёвая, процы быстрые (пох что питон треды нормально не умеет), так что идите обратно под камень, ретрограды.
Помню, как-то давно рассуждали, что все надобно писать на ассемблере, чтобы полнейшая автономность и монопольный доступ. А все эти высокоуровневые Си - для чайников.
> Помню, как-то давно рассуждали, что все надобно писать на ассемблере, чтобы полнейшая автономность и монопольный доступ. А все эти высокоуровневые Си - для чайников.Не, стопудов - языки программирования с высокоуровневыми конструкциями / абстракциями - это здорово. Но из всего множества языков с такими ствойствами имеет смысл выбрать наилучший, а не питон. Я вообще тормознее питона ничего не встречал. Может, руби на уровне - не уверен.
Но тут дело не только в тормознутости питона, а ещё и в логике самой программы. Реально, что они, кеш не умеют? Поисковые движки типа Lucene они тоже не умеют? А как шардинг делать они тоже не знают? А ограничение кол-ва запросов в секунду по каким-то критериям тоже неосилили запилить?
Или дело в том, что эта репа пакетов хостится на чьи-то сбережения накопленные с денег на обеды, а софт под неё разрабатывают добровольцы которые никому ничего не должны, радуйтесь что хоть такое написали?
В таком случае - при нехватке ни железных, ни разработческих ресурсов - конечно остаётся только отключить функционал. Непонятно только, как в таком положении может оказаться центральная репа топового по популярности языка программирования.
Фича питона в том что можно на коленке быстро сделать макет который вроде что-то даже делает в тепличных условиях. После этого запал заканчивается - работает же как-то....а потом приходит Волк и оказывается что дом из соломы и кирпича все-же немного отличаются.
А как иначе?
Нельзя теребить базу данных на каждый запрос. База данных не для того чтобы обрабатывать запросы, а для того чтобы хранить данные.
Только глупые питон программисты не понимают такую очевидную вещь
> Нельзя теребить базу данных на каждый запросда ну нафиг.
в нормальных БД потив этого кэширование есть.
Здравствуй ...опа, новый год!
Ну это спасибо контейнерным макакам, которые не могут по-человечески скрипты написать
Да, вот контейнеры тоже виноваты, не только хмл.
Дык xmlrpc это разве не жсон? ВОТ МЫ И ВЫЯСНИЛИ: ЖСОН ВО ВСЁМ ВИНОВАТ!11 Xml кстати вполне себе быстрый и эффективный, какие с ним проблемы могут быть? Ну если не упарываться по xmlscript или как там его, чисто для сериализации данных.
> Xml
> быстрый и эффективныйА ничего, что стандартной его реализации в природе не существет и каждый лепит кто во что горазд? XML это язык разметки а не реализация библиотеки.
Это вы вот сейчас серьезно? Каждая-каждая макака тут же способна отложить из под хвоста работающий парсер xml с xpath ?> XML это язык разметки а не реализация библиотеки.
угу, реализация называется libxml2 и libxsltproc
И именно потому, что.
А вы уже написали парсер xml?
Конечно json. Оно и называется
XMLrpc для того чтобы сразу было понятно что это тормозной json
Называется оно так по историческим причинам.
Вспоминаются запросы к DTD файлам, от которых как-то сайту W3C поплохело. Кэширование это сложно. У нас тут, понимаете ли, ОНЛАЙН.
> Поскольку ранее предлагалось удалить возможность поиска, то велика вероятность откладывания решения проблемы и объявления устаревшей имевшейся ранее функциональности поиска.Решение достойное достойнешего из отстойнеших :)
Я правильно понимаю, что это глобальная проблема и теперь никто не может загрузить пакет через pip?
Загрузить могут, но искать нет.
Правильно, питонистам некогда думать про circuit breaker-ы, rate limiter-в и прочие слишком сложные сложности software engineering - надо фичи поскорее писать, язык же такой удобный и ненапряжный, написал одну строку - и уже всё в продакшене, не то, что у ретроградов.
> питонистам некогда думатьдумать - это точоно не по твоей части, раз ты строишь такие нелепые обобщения
> сложные сложности software engineering
покажи-ка свой гитхаб/код, трепло, посмотрим, как ты усвоил уроки software engineering
Супер вектор для дудоса: добавить какое-то г-но в какие-то контейнера чтобы тупые макаки дудосили
>>Супер вектор для дудоса: добавить какое-то г-но в какие-то контейнера чтобы тупыеНе переживаем, уже все сделано - в одном из TIER-1 из top-5 одной отрасли на каждое разветрвыание docker`a при сборке коммита из vcs - происходит плять, клонирование gtest репки из внешней сети..
На предмет пару строчек для реализации паттенра "локальное хранилище", не неслышали - этта п*ц и а*уй... - и вот как-то git репка регла...
это верхушка, если че..
> Супер вектор для дудоса: добавить какое-то г-но в какие-то контейнера чтобы тупые
> макаки дудосилиЕще неплохо бы в это их pipi загрузить что-нибудь веселое. Все-равно эти макаки не проверяют нихрена.
> Поскольку ранее предлагалось удалить возможность поиска, то велика вероятность откладывания решения проблемы и объявления устаревшей имевшейся ранее функциональности поиска.Очень плохо! Собственный поиск для такого огромного репозитория как pip просто необходим. Пользоваться всякими гуглями для поиска в pip увидеть не лучшие пакеты, а рекомендованные с верху.
> необдуманное включение "pip search" в некие автоматизированные контейнеры.
Вот объясните мне хоть одну причину для которой надо "pip search" в контейнере? "pip search" необходим программисту для выбора готовых библиотек, а в собранном контейнере он ненужен, разве что для умышленного вредительства.
> Вот объясните мне хоть одну причину для которой надо "pip search"Откуда я знай? Так было в том вопросе на стековф откуда я скопипастил!
Мне некогда читать ответ - начальника сказал что если не запилим фичу до 16:00 сегодня - из меня сделает селедку под шубой. А если запилю - буду молодцом (или холодцом?)Мы уважаемая компания из top500, а не какой-то васянский подвал, где ты можешь тратить рабочее время впустую! (Иначе бы никакого вреда от единственного васянского контейнера с дерьмом и не было бы - ан, смотри-ка, смотри-ка - наш-то, наш-то - уже деплоют!)
Вы мне лучше объясните какого Лешего запросы на поиск идут в сетевую централизированную базу данных вместо скачанного локального индекса?
Остаётся одно, грепать https://pypi.org/simple/Данных с гулькин нос, их можно спокойно кинуть в раму даже на замом захудалом вертуальном сервере с небольшой обвязкой на той же ноде, го с нгинкс и будет счастье.
Спасибо. Мобильные браузеры убиваются :)Ещё бы такую же страницу с одними названиями, без ссылок, для краткости. И ещё одну с названиями и описаниями. И с поддержкой HTTP ranges. И пусть каждый их качает и грепает.
Десктопный FF тоже завис на этой странице, пришлось убить вкладку.
Ну да, мобилы от этого не в восторге.Эти идиоты даже не смогли в разбить этот массив данных на группы. Например: /aa, /ab, 1c и так далее.
> Например: /aa, /ab, 1c и так далее.Это ж тебе не перловики и плюсовики как в дебиановских репах :P
> Остаётся одно, грепать https://pypi.org/simple/сейчас допросишься - и его выключат!
> Данных с гулькин нос, их можно спокойно каждый раз тянуть и заново парсить э...280571 строк в
> поисках единственной нужной, на самом захудаленьком сервере, и будет щастье. Жаль что недолго.Поправил, не благодари!
Им нужно переходить на аналог Linux репозитория с зеркалами и так далее.py-get update && py-get search "ути-пути-питоняка-v2"
> сейчас допросишься - и его выключат!Ща потестим сколько RPSов это выдерживает. Надеюсь они на питоне это писали?
ктото смастерил скайнет и кликнул деплой?
Очередная крэпорепа пипнулась?
Ну и пёс с ней.
Так ничего ж неработает?!
Ничего не работает и всем наплевать
Типичный питон
Гвидо на пенсии, а пистон все не могут до свалки донести...
С разморозкой: он теперь «улучшает» питон в компании-лучшем друге опенсоурса мелкософте
Под чиьим управлением pip?
добавить rate limiter? Или запросы никак не связаны?
> добавить rate limiter?Вы хотите сказать что надо думать головой и программить нормально? ЫЫы, б$@, это ж думать надо, к тому же головой, питон к тому не располагает.
Ты хочешь сказать что это питон виноват что ты идиот?🤣 Может лучше учиться стоило, даунито?