Но какая разница? У вас ведь скрипты ещё и с базами данных общаются?
Предположим, написали вы сервис на чистом РНР без фреймворков, а для теста написали аналогичный сервис на Python/Django. Предположим, что на чистом РНР можно получить 10к запросов/сек, а на Django - жалкие 4к. Печаль.

Но ваш сервис, например, будет использовать 5 запросов к БД, каждый из которых будет отрабатываться за 1мс. 5мс - чисто на запросы к БД.

Итого: на РНР запрос будет выполняться за 5.0001мс, на Python/Django - за 5.00025мс... Неужели есть какая-то разница?

> python, html, c#

Внезапно PHP нет, а с ним было бы проще, ха-ха.

Грубо говоря, json.dumps конвертирует словарь в строку. json.loads конвертирует строку в словарь. Словарь - "ассоциативный массив". Но в вашем словаре ключ users возвращает список (настоящий, неассоциативный массив). Если там есть данные, то после выполнения

media = json.loads(api.json)

к нему можно обратиться с помощью конструкции

media['users'][0]['num']

Где 0 - элемент списка, данные с которого нужно получить. Массивы, ну вы знаете. Не забудьте проверить, есть ли в json ключ users и не нулевой ли длины этот список. Успехов!

Александр Александров, обратите внимание, что значения всего два - ровно по количеству воркеров uwsgi.

Если никто не против, расскажу небольшую историю. Когда-то, когда я писал первое приложение на Flask, я решил, что постоянно драть сервер БД ради практически неизменных данных неразумно, и кешировал их локально. Локально, Карл! В переменных. И передавал их в шаблонизатор. А потом я выложил своё творение в сеть и тоже поставил два воркера на uwsgi. И стоило мне добавить раздел меню, как я получал странную ситуацию: на части запросов сайт отображался с созданным меню, а иногда показывалась "старая" версия. Что логично, локально (на дев-сервере) всё работало замечательно.

Roman Kitaev всенепременно прав, в коде ошибка, не в nginx и не в uwsgi.

UPD: дело в том, что воркеры uwsgi запускают изолированные процессы, каждый со своим набором данных, соединением с БД/кешами прочими няшностями. Локально в таком случае ничего нельзя хранить. Если очень хочется, стоит присмотреться к асинхронным фреймворкам с единственным процессом.

Pure Python не применяется в веб-разработке потому, что... придётся писать свой веб-сервер, который будет слушать 80-ый порт, принимать запросы и вертать взад ответы. Хотя постойте, зачем писать веб-сервер? Есть же nginx! А приложения на Python веб-сервер отдаёт через uwsgi. Да! Тогда надо написать что-то, что будет отдавать в uwsgi сгененированный ответ. Получится что-то типа Werkzeug (часть Flask). Или что-то типа Gevent. Или что-то типа Twisted. Или что-то типа Tornado. Или что-то типа wheezy.web. Что-то, что называется WSGI-сервером. А потом на нём придётся сделать что-то типа фреймворка Bottle, чтобы можно было быренько и красиво делать то, ради чего это всё было написано.

Но... Тут возникают странные мысли насчёт того, есть ли в этом смысл? Может, стоит переложить эту задачу на чужие плечи? Даже в этом ответе уже есть до черта WSGI-серверов, которые написаны людьми, куда более сведущими в этом вопросе. Может быть, стоит сосредоточиться на самом процессе написания приложений, используя уже готовые фреймворки? Рождение ещё одного фреймворка не сделает мир лучше.