Я про очень конкретный пример.

можно дернуть сишную либу, которая внутри себе сделает pthread_create

Я про очень конкретный пример.

я хз, как в монге на уровне клиента реализована асинхронность (если реализована), но если там для нее используются питоновские потоки - то это, мягко скажем, странно

Есть кто-нибудь с опытом работы с API ВКонтакте? Можно ли там получить данные своих переписок через запрос?

Я всё про конкретику, про mongodb. Там именно так, как я сказал. Не улетайте в теорию :) Если я последую за Вами, у нас спора нет, потоки на фиг не нужны. Просто перелопатить сишные либы.

Есть кто-нибудь с опытом работы с API ВКонтакте? Можно ли там получить данные своих переписок через запрос?

можно

я хз, как в монге на уровне клиента реализована асинхронность (если реализована), но если там для нее используются питоновские потоки - то это, мягко скажем, странно

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

Я всё про конкретику, про mongodb. Там именно так, как я сказал. Не улетайте в теорию :) Если я последую за Вами, у нас спора нет, потоки на фиг не нужны. Просто перелопатить сишные либы.

именно, все так. Потоки в cPython нафиг не нужны почти никогда, за исключением тех случаев, когда единственная альтернатива - переписывать сложную сишную либу

но люди ленивые, поэтому мы имеем до сих пор кучу поточных фреймворков потипу flask/django

Короче, в стопитсотый раз холивар наш приходит к теме "от задачи всё зависит".

Короче, в стопитсотый раз холивар наш приходит к теме "от задачи всё зависит".

так это-то очевидно ? я не холиварил, мне искренне хотелось понять профит от второго потока в задаче Дениса

и я до сих пор его не понял

Дык он задачу не изложил, вот и непонятно.

дык он написал, что там большей частью I/O операции. Это хорошо, да, но, тем не менее, само наличие потока и функции питона в нем подразумевает, что системный шедулер будет бегать и переключать контекст, а GIL будет браться, блокируя работу другого потока

чего можно было бы избежать, будь все I/O в одном потоке

ну не умеет питон пока как Go, ну сорян

Меня ещё дико бесят всякие новомодные штучки типа реактивного подхода. Вот делают либу PyRX, казалось бы всё реактивное, идеальное для ассинхронности. Так нет. Внутрь залезаешь, значит там всё сделано синхронно, а для закрывания тикета на гитхабе про ассинхронность лепят жуткие костыли, что это нифига не работает. Вот куча либ видел, которые хотят на двух стульях посидеть, и python 2.7 поддержать, не используя async/await, и ассинхронными быть. В результате беда-беда.

Меня ещё дико бесят всякие новомодные штучки типа реактивного подхода. Вот делают либу PyRX, казалось бы всё реактивное, идеальное для ассинхронности. Так нет. Внутрь залезаешь, значит там всё сделано синхронно, а для закрывания тикета на гитхабе про ассинхронность лепят жуткие костыли, что это нифига не работает. Вот куча либ видел, которые хотят на двух стульях посидеть, и python 2.7 поддержать, не используя async/await, и ассинхронными быть. В результате беда-беда.

+1

есть такая либа aiofiles, например

так там в ней ничего асинхронного нет вообще, кроме обертки вызовов в корутины зачем-то

это мило, конечно, но не сильно помогает на практике

Я сейчас для души себе проектик начал, бэкендик с вебинтерфейсом. Вот ещё не раскачегарился, а уже 3-4 либы такие использую, криворукие...

Короче, даёшь ассинхронную революцию. Всё синхронное принудительно стереть, запретить питон 2.7.

Я сейчас для души себе проектик начал, бэкендик с вебинтерфейсом. Вот ещё не раскачегарился, а уже 3-4 либы такие использую, криворукие...

есть вот шикарное видео на эту тему https://www.youtube.com/watch?v=Fj2t959Q7DA

40 минут? Ок :)

Короче, даёшь ассинхронную революцию. Всё синхронное принудительно стереть, запретить питон 2.7.

да пиши на го просто критичные участки

40 минут? Ок :)

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

Нет, уровень фанатичности преданности питону на 100%.

Никаких го, руби, р и всё такое.

Нет, уровень фанатичности преданности питону на 100%.

а как же “инструмент по задаче”?

Дык в задачу входит фанатичный программист.

руби и р-то понятно, это мертвые языки, но го на многих задачах очень даже

да пиши на го просто критичные участки

кстати вопрос сразу задам как связать такие вещи? ну допустим участок на питоне, участок на го

кстати вопрос сразу задам как связать такие вещи? ну допустим участок на питоне, участок на го

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

можно тупо байты пересылать через юникс сокеты

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

микросервисную архитектуру вообщем делать?

в эрланге вот порты придумали для такого

микросервисную архитектуру вообщем делать?

ну да, типа того

Я в своё время для сильно разнородного взаимодействия использовал Zeroc Ice. Впечатления приятные.

Меня ещё дико бесят всякие новомодные штучки типа реактивного подхода. Вот делают либу PyRX, казалось бы всё реактивное, идеальное для ассинхронности. Так нет. Внутрь залезаешь, значит там всё сделано синхронно, а для закрывания тикета на гитхабе про ассинхронность лепят жуткие костыли, что это нифига не работает. Вот куча либ видел, которые хотят на двух стульях посидеть, и python 2.7 поддержать, не используя async/await, и ассинхронными быть. В результате беда-беда.

Вообще питон - это призвание, а если хотите асинхронщину, то идите в ноду.

Вообще питон - это призвание, а если хотите асинхронщину, то идите в ноду.

в го, идите в го

ноде пора на свалку истории неудачных решений

Вообще питон - это призвание, а если хотите асинхронщину, то идите в ноду.

Был я там. До сих пор решают элементарные штуки, про которые я лет десять назад забыл.

ноде пора на свалку истории неудачных решений

как будто го удачное решение, особенно в части работы с ошибками, особенно в части написания бесконечных if err != nil { return nil, err }

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

как будто го удачное решение, особенно в части работы с ошибками, особенно в части написания бесконечных if err != nil { return nil, err }

их необязательно писать так-то. Можно обработку ошибок по-разному сделать

и да, го - гораздо более удачное решение, чем нода

Ну то есть если официальная дока нам говорит, что выпускайте проект в продакшн только с оберткой, которая рестартнёт ваш сервис, когда он сдохнет... Ну.... Ок.

и да, го - гораздо более удачное решение, чем нода

нууу я бы поспорил

нууу я бы поспорил

даже не начинай ?

для начала хотя бы ядра научитесь грузить равномерно

для начала хотя бы ядра научитесь грузить равномерно

там уже даже вроде запилили всякие потоки в ноду, правда несколько экспериментально, и вообще нода не для cpu bound задач

Правда Go кстати тоже не особо для числодроблений подходит

там уже даже вроде запилили всякие потоки в ноду, правда несколько экспериментально, и вообще нода не для cpu bound задач

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

Правда Go кстати тоже не особо для числодроблений подходит

ну это потому что нормальных BLAS-связок нет пока что

но, имхо, для числодроблений еще Rust зайдет

ну это потому что нормальных BLAS-связок нет пока что

я вот уверен, что для числодробилок ещё ничего лучше C++ не придумали

я вот уверен, что для числодробилок ещё ничего лучше C++ не придумали

ты хотел сказать, фортрана

ты хотел сказать, фортрана

нет

я вот уверен, что для числодробилок ещё ничего лучше C++ не придумали

С

С

тоже нет

почему нет

А про джаву все забыли

ты хотел сказать, фортрана

Ассемблера

нет

лучшая на настоящий момент векторная библиотека - Numpy - базируется на фортрановых либах для BLAS

А про джаву все забыли

Java is dead

ERROR: S client not available

А про джаву все забыли

Опять же нет

А про джаву все забыли

джава не умеет в “близко к железу”, это не ее область

почему нет

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

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

никто в здравом уме не будет для числодробилок использовать плюсовый STL

никто в здравом уме не будет для числодробилок использовать плюсовый STL

Где я говорил про STL?

Где я говорил про STL?

C++ без STL - это С с классами

C++ без STL - это С с классами

Чеееегоооо?

Чеееегоооо?

тогоооооо

никто в здравом уме не будет для числодробилок использовать плюсовый STL

ну смотря как использовать

Вообще то можно (а иногда и нужно) написать свои специализированные классы на шаблонах и с перегрузкой операторов

элементарные операции на BLAS, конечно

а там - как пойдёт

Вообще то можно (а иногда и нужно) написать свои специализированные классы на шаблонах и с перегрузкой операторов

но не в случае числодробилок, где важны вектора и раскладка по кэшам и SSE-инструкциям

Вообще то можно (а иногда и нужно) написать свои специализированные классы на шаблонах и с перегрузкой операторов

и я бы не назвал это Си с классами

но не в случае числодробилок, где важны вектора и раскладка по кэшам и SSE-инструкциям

а кто мешает на крестах такое сделать?

и я бы не назвал это Си с классами

ну да, там теперь есть еще auto и лямбды

и завернуть в обёртки на классах и шаблонах

а кто мешает на крестах такое сделать?

никто, но и на C никто не мешает. И на C чаще всего это и делают

и завернуть в обёртки на классах и шаблонах

ну, можно еще из буханки хлеба троллейбус сделать

никто, но и на C никто не мешает. И на C чаще всего это и делают

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

у кого есть сертификат питон программиста

ну, можно еще из буханки хлеба троллейбус сделать

так что как раз на сишке и будет уродливый троллейбус из буханки

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

большинство этого и не нужно, если в задаче стоит “максимально эффективно использовать железо”, а не “доверять компилятору, что он максимально эффективно использует железо"

для таких вот задач

так что как раз на сишке и будет уродливый троллейбус из буханки

нет

в си есть структуры, макросы. А перегрузка операторов мне и даром не нужна

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

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

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

доверие развесистому компилятору в таких вещах - ну такое

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

нет, не будет, лол

там будет компилятор, который придет и за тебя наоптимизирует хероты

доверие развесистому компилятору в таких вещах - ну такое

нууууу нет, я больше доверяю компилятору честно говоря