Чтоб парсить данные о пользователях в Инстаграме нужно авторизоваться? Какую библиотеку нужно использовать?

Есть варианты ? на гитхабе есть instapy но он прямо скажем не огонь

Python, походу, упорно стремится на путь C++ с его адской complexity

ага, куча неявной херни досыпается в язык заместо более важных вещей

Добавили один оператор за 20 лет, а они уже про c++ complexity запели)

Чтоб парсить данные о пользователях в Инстаграме нужно авторизоваться? Какую библиотеку нужно использовать?

И да, нужно. А ещё если ты совершил два запроса за очень короткий промежуток времени, или что-то подобное, то твой айпи кидают в подобие черного списка.

Добавили один оператор за 20 лет, а они уже про c++ complexity запели)

не один, был еще @

ага, куча неявной херни досыпается в язык заместо более важных вещей

А что нужно питону важного на ваш счёт?

А что нужно питону важного на ваш счёт?

ускорение работы эвентлупа, переписывание большинства встроенных методов на си вместо питона, возможность плодить несколько легких процессов интерпретатора в одном системном

это все на порядок важнее оператора моржа

Вот не факт

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

это все на порядок важнее оператора моржа

Важнее для кого? Что вы пишите на питоне, что вам жизнено необходимы такие доработки?

Язык должен развиваться

Вот не факт

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

Важнее для кого? Что вы пишите на питоне, что вам жизнено необходимы такие доработки?

например, веб-приложения

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

Ты так говоришь будто оператор моржа вся команда питона пилила целый год

Язык должен развиваться

ну да, давайте больше фич досыпем и пофиг на рефакторинг. Знакомая картина, где-то видел

Да его за день вмержили

например, веб-приложения

А какой это прирост даст? Есть какие то предложожения на этот счет?

Ты так говоришь будто оператор моржа вся команда питона пилила целый год

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

ускорение работы эвентлупа, переписывание большинства встроенных методов на си вместо питона, возможность плодить несколько легких процессов интерпретатора в одном системном

1 и 2 к языку отношения не имеют

Короче, я жду эту штуку с нетерпением)

А какой это прирост даст? Есть какие то предложожения на этот счет?

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

1 и 2 к языку отношения не имеют

имеют отношение к ванильной его реализации

Короче, я жду эту штуку с нетерпением)

извращенец

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

Процессы не параллелят по-настоящему?

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

А чем ProcessPool не подходит?

Процессы не параллелят по-настоящему?

процессы в текущей реализации дают дикий оверхед на сериализацию и синхронизацию

настолько дикий, что тупой GNU Parallel рвет питон по скорости на два порядка

настолько дикий, что тупой GNU Parallel рвет питон по скорости на два порядка

эт что?

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

https://www.python.org/dev/peps/pep-0554/

процессы в текущей реализации дают дикий оверхед на сериализацию и синхронизацию

++

эт что?

это консольная утилита на перле для запуска параллельных процессов

процессы в текущей реализации дают дикий оверхед на сериализацию и синхронизацию

а есть от этого какой то выход?

а есть от этого какой то выход?

Не юзать питон)

а есть от этого какой то выход?

есть, например, позволять запускать процессы в режиме пересылки сырых байтов между ними, а не пиклованных питонообъектов

с минимальным оверхедом поверх системных вызовов

просто fork() и pipe()

есть, например, позволять запускать процессы в режиме пересылки сырых байтов между ними, а не пиклованных питонообъектов

Пересылать сырые байты мешает гил

просто fork() и pipe()

Разве нельзя сейчас организовать такое на python?

Пересылать сырые байты мешает гил

GIL? в мультипроцессинге? ну-ну

Пересылать сырые байты мешает гил

А причем тут Гил и процессы?

просто fork() и pipe()

реально?

GIL? в мультипроцессинге? ну-ну

Так это же не мультипроцессинг будет, если мы просто память копируем. Ссылки на глобальные структуры те же останутся

у меня так жопа с этого горела

Разве нельзя сейчас организовать такое на python?

на чистом Python будет сложно, проще будет на C писать

Так это же не мультипроцессинг будет, если мы просто память копируем. Ссылки на глобальные структуры те же останутся

я про pipe не просто так написал

я про pipe не просто так написал

А тогда надо сериализовывать

А тогда надо сериализовывать

не надо, берешь байты и шлешь

все конвейеры в юниксе так работают еще с 80-х годов

не надо, берешь байты и шлешь

Байты это указатель на глобальный объект нашего интерпретатора, что с ними делать получателю?

на чистом Python будет сложно, проще будет на C писать

Ну это может показаться банальным, но C extension никто не отменял. Да и pull request никто не запрещает делать в cpython ;)

Байты это указатель на глобальный объект нашего интерпретатора, что с ними делать получателю?

байты - это не указатель на глобальный объект интерпретатора

не надо пересылать указатели

Байты это указатель на глобальный объект нашего интерпретатора, что с ними делать получателю?

Потоки товарищь

байты - это не указатель на глобальный объект интерпретатора

В питоновских объектах много указателей внутри

В питоновских объектах много указателей внутри

мне кажется, ты троллишь

В питоновских объектах много указателей внутри

Ты понимаешь, что такое IOStream?

Ты понимаешь, что такое IOStream?

Понимаю, и?

В питоновских объектах много указателей внутри

Ну тогда причем тут Bytes и способ хранения в python?

Ну тогда причем тут Bytes и способ хранения в python?

При том, что какие именно данные ты суешь в iostream?

При том, что какие именно данные ты суешь в iostream?

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

зато оно будет работать на порядки быстрее

Сырые байты и сейчас можно пересылать

Сырые байты и сейчас можно пересылать

через 100 слоев ненужной абстракции, да

либо же дергая руками системные вызовы из libc

Можно и без, шаред мемори есть

ну такое

multiprocessing.shared_memory

Даже в си ходить не надо

multiprocessing.shared_memory

но зачем, если мне нужна обычная потоковая обработка?

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

это дефолтный механизм, которому больше 40 лет

Ты и пайп можешь сейчас сделать

multiprocessing.shared_memory

туда же не все запулить можно не?

туда же не все запулить можно не?

Любые байты можно

ну точнее

часть будет сериализоваться

Ты и пайп можешь сейчас сделать

os.mkfifo?

ну такое

А разве в каких-то интерпретируемых языках нет сериализации и десериализации при создании процесса?

а где мой синтаксический сахар? где поддержка этого режима в мультипроцессинге?

multiprocessing.Pipe

А разве в каких-то интерпретируемых языках нет сериализации и десериализации при создании процесса?

я ничего не имею против того, что она есть по дефолту. Я против того, что нет никакого низкоуровневого опционального режима для ускорения

multiprocessing.Pipe

не катит, как раз тут и есть тот самый гигантский оверхед

дайте мне просто буфер и я буду в него writeinto()

не катит, как раз тут и есть тот самый гигантский оверхед

Там есть send_bytes

дайте мне просто буфер и я буду в него writeinto()

а тупо в dev/shm писать

Там есть send_bytes

ну давай сравним его по производительности с  GNU Parallel?

а тупо в dev/shm писать

кроссплатформенно?

)0

ну давай сравним его по производительности с  GNU Parallel?

Никогда не интересовался таким, можно сравнить

Никогда не интересовался таким, можно сравнить

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

в винде чуть похитрее, но тоже не особо сложно

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

а есть вообще место где это зашарить?

или только кусками из доков выцеплять информацию?

а есть вообще место где это зашарить?

в смысле?

или только кусками из доков выцеплять информацию?

ну, есть базовые системные вызовы же

почитай про fork() и всякие execve() в сях

ну, есть базовые системные вызовы же

это все хорошо когда ты работаешь с си на линуксе