Господа, скажем у вас есть проект на #python3 (SaaS) и вам нужно хранить логин/пароли ваших пользователей к 3rd party системам (интеграции). Т.е. нельзя хранить хеши, нужны сами креды, т.к. код будет с ними логиниться в другие сервисы. Хостимся в AWS. Можно хранить в зашифрованном виде, да? Может для этого есть какие-то сервисы, компоненты готовые?

Хранить в БД нельзя по каким причинам?

в системных переменных хранить можно

Хранить в БД нельзя по каким причинам?

Наверное можно. Интересны мнения

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

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

не линукс пользователи, а пользователи SaaS

Если сервис, то можно хоть в LastPass класть :)

Либо уже недавно обсуждавшийся Vault от hashicorp

https://www.onionid.com/products/secret-storage/ Еще такая хрень есть

Vault любопытно. Тут еще есть сравнения с другими системами https://www.vaultproject.io/intro/vs/custom.html

Так, а теперь давайте выясним, а что же @nazarov_tech к нам не пришел вчера?

мы не в месте, но я откровенно каюсь( хотя меня и мало кто ждал ;)

https://m.facebook.com/story.php?story_fbid=10155260774054162&id=692029161

Угу.

мы не в месте, но я откровенно каюсь( хотя меня и мало кто ждал ;)

А да, ты ещё:)

мы не в месте, но я откровенно каюсь( хотя меня и мало кто ждал ;)

Меня тоже никто не ждал, но в итоге нормально так погудели :D

Так, а теперь давайте выясним, а что же @nazarov_tech к нам не пришел вчера?

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

Генеральному директору ООО 'Питон-технологии Петербург' Сержу Матвеенко ОБЪЯСНИТЕЛЬНАЯ

мы не в месте, но я откровенно каюсь( хотя меня и мало кто ждал ;)

я ждал, Лёша =) но сам не пришёл в итоге. И ты хороший, поэтому неправда про 'мало кто'. Вырывайся на следующие дринкапы обязательно, у нас много новых крутых людей :)

Что-то новый год тебя как-то раскочегарил.

Что-то новый год тебя как-то раскочегарил.

что? :D

Да что не новость, все где-то бухаешь жестоко :)

:)

Какое место для дринкапа выбрали в этот раз?

https://twitter.com/tdierks/status/835912924329836545

Коллеги, мне тут ткнули пальцем в этот канал, и сказали, что здесь есть много умных людей ?

Может кто-нибудь из умных людей подсказать годную библиотеку, которая делает акторы?

Своими силами нагуглил pykka, но он как-то ни о чём, почти ничего не умеет.

И Thespian от Godaddy, но у него какие-то сложности с автотестами, как-то стыдно такое людям отдавать.

Может кто-нибудь из умных людей подсказать годную библиотеку, которая делает акторы?

Чтобы что? Чтобы иметь кооперативную многозадачность и только лишь?

Скорее, чтобы поиграться. Мне по службе пришлось ковырять akka, и мне понравилось, хочу на чём-то более родном сделать то же самое.

Скорее, чтобы поиграться. Мне по службе пришлось ковырять akka, и мне понравилось, хочу на чём-то более родном сделать то же самое.

Erlang?

))

Нет, не настолько)))

Вообще, на мой вкус, цимус в том, что акторы — это такое очень логичное развитие ООП в мире многопоточных приложений. Концепция «всё есть объект» заменяется на «всё есть актор», и вместо набора методов появляется набор сообщений. Получается гораздо изящнее, чем напрямую использовать потоки.

Вообще, на мой вкус, цимус в том, что акторы — это такое очень логичное развитие ООП в мире многопоточных приложений. Концепция «всё есть объект» заменяется на «всё есть актор», и вместо набора методов появляется набор сообщений. Получается гораздо изящнее, чем напрямую использовать потоки.

Поговаривают, изначально так всё и было.

Но...?

Но пришли глиномесы, сломали ооп и посадили на него

Никаких но. Ты пишешь, что "заменяет, появляется". Насколько я помню, это объекты в нынешнем понимании заменили сообщения, а не наоборот.

Сообщение — это указание на то, что надо делать, иногда данные, с которыми нужно что-то делать. В принципе, то же самое, что вызов метода (с параметрами). Или я не о тех сообщениях?

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

Самый настоящий ООП язык имеет динамическую типизацию.

Самый настоящий ООП язык имеет динамическую типизацию.

чо?

Smalltalk.

что Smalltalk?

Динамический язык.

динамическая типизация и ООП - понятия, друг с другом не связанные

И?

можно в ООП-стиле писать на Scala и заставлять все проверки типов за тебя делать компилятор

и это будет куда лучше динамики

в питоне ООП так себе, отчасти именно из-за его слишком большой динамичности

Человек просто спросил про библиотеку и началось...

Ну, оно вообще говеное, а не так себе.

Вообще, на мой вкус, цимус в том, что акторы — это такое очень логичное развитие ООП в мире многопоточных приложений. Концепция «всё есть объект» заменяется на «всё есть актор», и вместо набора методов появляется набор сообщений. Получается гораздо изящнее, чем напрямую использовать потоки.

ну посмотри на asyncio, поверх этого можно и акторы организовать

Поверх асинкайо можно себе баттхерт жопы организовать

Впрочем ладно.

Человек просто спросил про библиотеку и началось...

А вот так оно и бывает, да))

asyncio - лучшее, что с питоном за последние несколько лет случалось)

Расхожая фраза, но чет сомненительно.

ну чет факт

Лучше другая реализация бы приключилась)

например?

ERROR: S client not available

asyncio - лучшее, что с питоном за последние несколько лет случалось)

Ну, хорошо бы, чтобы это не было так, а то хана Питону тогда.

Ну, хорошо бы, чтобы это не было так, а то хана Питону тогда.

наоборот

Вообще, на мой вкус, цимус в том, что акторы — это такое очень логичное развитие ООП в мире многопоточных приложений. Концепция «всё есть объект» заменяется на «всё есть актор», и вместо набора методов появляется набор сообщений. Получается гораздо изящнее, чем напрямую использовать потоки.

Здравствуй Golang:)

сейчас довыпилят gil, сделают полную генераторность и go с нодой будут отдыхать

а там уже можно будет по пути Pyston идти

и развивать JIT на LLVM

сейчас довыпилят gil, сделают полную генераторность и go с нодой будут отдыхать

Довыпилят GIL?

и многие проблемы со скоростью питона останутся в прошлом

Довыпилят GIL?

ну вообще в 2016 на пайконе доклад был

о том, что gil уже почти выпилили и оно работает

GIL выпилят, станет не thread-safe?

Довыпилят GIL?

Из CPython?

GIL выпилят, станет не thread-safe?

ну почему же, есть STM в Pypy

Giloctomy

о том, что gil уже почти выпилили и оно работает

Покажи

Giloctomy

gilectomy

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

https://github.com/larryhastings/gilectomy

Покажи

Есть подозрение, что кто-то не допонял контекст

https://www.youtube.com/watch?v=P3AyI_u66Bw

Хотели же вроде даже в Py 3.6 это сделать, но что-то пошло не так

Вообще, на мой вкус, цимус в том, что акторы — это такое очень логичное развитие ООП в мире многопоточных приложений. Концепция «всё есть объект» заменяется на «всё есть актор», и вместо набора методов появляется набор сообщений. Получается гораздо изящнее, чем напрямую использовать потоки.

где эти сообщения хранить? как исполнять акторы?

А это уже детали реализации ?

asyncio - лучшее, что с питоном за последние несколько лет случалось)

нет.

нет.

да же, как нет-то

Хотели же вроде даже в Py 3.6 это сделать, но что-то пошло не так

Никто не хотел. https://github.com/larryhastings/gilectomy/blob/gilectomy/README.md

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

а там уже можно будет по пути Pyston идти

пистон похоронен.

пистон похоронен.

он не похоронен, он отдан на поддержку комьюнити