softshape: вот теперь вдвойне не понятно, зачем у вас какой-то модуль, работающий с веб-сессиями оказался установлен через pip вне виртуального окружения )
therhino: от роботов, которые его будут вызывать без данных/с неправильными данными? Просто проверяйте наличине параметра code и отдавайте какой-нить Bad Request 400, если параметр не передан. Если параметр передан - то это либо честный параметр от ВК, которому я бы доверял, либо какой-нибудь невалидный кусок данных. Тут вам поможет сам ВК, он отвечает 401 Not Authorized, если попробовать получить access_token по плохому code. Просто добавьте обработку на этот случай в своем контроллере. Не думаю, что "от роботов" нужно защищаться заранее, сначала я бы посмотрел на природу их действий.
В вашем примере access_token передается в URL fragment (то, что после знака #). Такие данные не передаются браузером на сервер при посещении страницы. На сервере запрос вида localhost:3000/api/sessions/signin#access_token=xxxxxxx&expires_in=86400&user_id=xxxxxxx будет выглядеть просто как localhost:3000/api/sessions/signin без каких либо параметров.
become_iron: если вам действительно нужно сохранить эти скрипты независимыми, то IPC - это то, что нужно. Открывайте pipe, например, и стройте синхронизацию поверх него. Первый скрипт выполнил действие - сделал запись в канал и начинает блокирующее чтение из канала. Второй скрипт получил сообщение из канала - выполнил действие, сделал запись в канал, разблокировав первый скрипт. Сам же снова подвис на чтении из канала. И так далее.
become_iron: если я правильно понял - у вас 2 независимые программы на Python. И нужно реализовать между ними взаимодействие, в частности, синхронизацию выполнения каких-то циклов?
Андрей Дугин: Да, ваше новое решение просто отличное. У меня схожие, но видимо не столь радикальные взгляды, поэтому я упомянул в своем ответе лишь zip и list comprehension.
Андрей Дугин: речи про оптимальный код не было. Автор вопроса только учится программировать. Ему сейчас нужно разобраться с построением алгоритмов. Да, ваш вариант решения быстрый - но посмотрите, со сколькими новыми концепциями придется познакомиться автору вопроса? 2 новых модуля, итераторы, исключения! Это питоник-код, да, я же писал скорее просто понятный алгоритм на псевдокоде.
dllweb: DI - это на самом деле очень просто. Берете и явно (ключевое слово именно явно) передаете зависимости в код, который их требует. Через параметры функции/метода или через конструктор. А DIC - это о том, как этот процесс автоматизировать/универсализировать на уровне сервисов веб-приложения. Т.е. у вас есть куча сервисов, каждый явно определяет, от каких других сервисов он зависит (через параметры конструктора). А DIC умеет создавать экземпляры сервисов, скармливая им экземпляры тех сервисов, от которых они зависят.
Дмитрий Энтелис: видел я пару проектов, где из-за таких рассуждений потом все классы обросли __get и __set, которые оборачивали свойства, которые раньше были публичными и пытались хоть как-то решить проблему полного отсутствия инкапсуляции. Хоть уже и ценой падения производительности из-за постоянных вызовов магических методов.
Stadinov Denis: как что-то, требующее парсинга, может работать быстрее непосредственно хранения данных в самом PHP? Результаты профилирования в студию!) Обычный пользователь - понятие растяжимое. У кода на PHP обычный пользователь скорее всего и сам программист. И как программист могу сказать, что удобнее читать код, чем ini-файлы )
brainick: для первой книги по C ничего лучше не придумать. Для первой книги о программировании в принципе - да, не годится, так как пропущена вводная часть о том, что собсно, такое программирование.
Pavel Denisov: Временная сложность поиска и добавления элемента в set и dict одинаковая. По поводу тестов - согласен. Правда в свете обновленных условий вопроса - количество различных s не определено, я бы стал смотреть уже вот в этом направлении https://toster.ru/answer?answer_id=528145.
Станислав Фатеев: Упс, я исходил из предположения, что s одна и та же. Тогда можно индекс сделать двойной вложенности, сначала по s, затем по word или наоборот. В зависимости от частотности. Плюс можно делать md5(s) в качестве ключа индекса, чтобы не хранить строку целиком.
Gorily: на стороне клиента будет всего одно действие: select * from my_stored_procedure(). И хранимка сама по себе будет содержать всего один select и один insert.
Gorily: Тогда попробуйте сделать хранимую процедуру, в которой сначала делать выборку всех уже существующих id в таблице в массив, а затем вставку только тех строк, id которых в массиве не оказалось. Не совсем SQL-решение конечно, но сведется к одному SELECT и одному INSERT + цикл по массиву. До каких-то пределов по кол-ву id в одной выборке должно работать нормально.
