Zanak

Почитал ответы коллег, и решил вставить свои 5 копеек:
- multiprocessing. каждая задача - это полноценный процесс ОС. процессы могут быть одинаковые, или абсолютно разные. для взаимодействия между процессами используются сокеты (про udp тактично промолчим). сокеты бывают 2 видов, сетевые и unix (юникс сокеты, естественно, присутствуют на юникс системах, под windows возможно присутствует аналогичный механизм IPC, но я не в теме, поэтому не стану сбивать вас с толку). принципиальное отличие для сокетов - это то, что через юникс сокеты взаимодействие возможно только в пределах одной машины, для сетевых сокетов такого ограничения нет.
- multithreading. главное отличие от процессов - нельзя создать самостоятельный поток, всегда сначала стартует процесс, который это делает. с точки зрения планировщика ОС отличие потоков от процессов весьма небольшое - процессы стартуют каждый в своем адресном пространстве, со своим стеком и дескрипторами. все потоки, делят адресное пространство с родителем и другими потоками. из плюсов - взаимодействие между потоками максимально быстрое, его возможности ограничены только фантазией автора программы. из минусов - взаимодействие между потоками возможно только в рамках одной программы, взаимодействие со внешним миром не отличается от случая множества процессов, из за того, что все данные доступны всем потокам сразу, приходится использовать специальные техники программирования с участием блокировок.
- асинхрон. асинхронное програмирование - это есть ни что иное, как кооперативная многозадачность. всегда есть диспетчер, который умеет переключать асинхронные задачи. в некоторых новомодных языках, вроде go, компилятор неявно вставляет вызовы диспетчера, чтобы горутины могли исполнятся паралельно. в языках, где поддержка асинхронности появилась позже, чем сам язык приходится в явном виде указывать вызываем мы синхронный или асинхронный код. при вызове асинхронного кода происходит вызов планировщика, который добавляет запрошенную функцию в очередь и производит переключение на другую задачу. иногда приходится в явном виде обращаться к диспетчеру, если, например, наша асинхронная задача будет исполняться заведомо долго.

Такой вариант вроде работает:

package main

import "fmt"

func sum(s []int) int {
	result := 0
	for _, v := range s {
		result = result + v
	}
	return result
}

func main() {
	n := 10000
	var stack []int
	p := n - 1
	for p > 0 {
		stack = append(stack, p)
		for j := p - 1; j > 0; j-- {
			stack = append(stack, j)
			cur := sum(stack)
			if cur < n {
				continue
			} else if cur == n {
				fmt.Printf("%++v\n", stack)
			}
			stack = stack[:len(stack)-1]
		}
		stack = nil
		p--
	}
}

Прошу прощения, на node не пишу.

Такое возможно, если речь о сервисах. Пишете спеку для swagger-а, с помощью их тула генерируете болванку сервиса, допиливаете реализацию в ручную (я не помню, генератор заполняет обработчики кодом, или оставляет их пустыми). Правда это работает только при создании сервиса с нуля, поддерживать существующий код вам все равно придется руками :)
Для приложений первичны, скорее всего, данные, с которыми вы работаете, чем методы их использования. Поэтому, для приложений, такой подход к разработке лучше не использовать, как мне кажется.

1. У вас компилится windows-gui приложение. Попробуйте явно посмотреть в сторону -m параметра для g++ и добавить правильное значение в ваш cmd сценарий. Форточек под рукой нет, подробнее сказать не могу.
2. Эта функция вроде как запускает вашу команду с указанными параметрами и ждет завершения, разве нет? (Это по поводу ожидания завершения)

Лучше бы увидеть вашу вьюху, потому что странно, в том виде, как вы описываете, проблем быть не должно.
Вот чего гугл предложил на запрос "python flask render_template plain html": раз, два, три, ну и четыре.

А при чем здесь rest?
1. у вас сервис, запущенный на рабочей станции, должен лить картинки на сервер. если вам обязательно хочется использовать http, используйте http.client, как вариант.
2. как вариант, можно запилить свой клиент/сервер для доставки скриншотов в админку. можно обойтись и штатными модулями.
3. а вот смотрелку, того что вам станции насыпали, можно запилить на чем угодно, например на django.

Во первых, разве вызов super не должен выглядеть так:
super(Example, self).__init__()?
Когда мы переопределяем метод в потомке класса, то мы можем заново реализовать всю работу этого метода, и тогда вызов super не нужен вовсе.
Если мы хотим только немного изменить поведение метода, то нам остается в подходящем месте встроить вызов метода родителя, сообщив среде исполнения родителя какого типа мы ищем (в вашем случае Example) и ссылку на текущий экземпляр (это self).
Теперь собственно ответ на ваш вопрос: инициализация класса родителя может быть сложным процессом, потому что свойства предка сами могут быть объектами, которые важно правильно построить и инициализировать, и если вы не готовы делать это сами, в каждом случае, когда создаете нового наследника, то вы можете вызвать super.
Только вызывайте его правильно. :)

jsonify не спасет отца русской демократии? :)

1. Не очень понял, зачем вы использовали g. Просто для накопления данных в процессе обработки хватило бы и обычной переменной, а для хранения данных между запросами она не применима (Смотрите замечание на этот счет).
2. Если вы сами ловите исключение, то и обрабатывать его лучше полностью, с указанием шаблона и кода ответа. На вашу проблему это не влияет, но это просто хорошая привычка, не делать ни чего, или доделывать до конца.
3. Что подразумевает return внутри блока with? Если объявить переменную аккумулятор значений из файлов выше цикла по файлам, и вместо g.data_local ... и return ... написать код отправки прочитанного значения в накопитель, например как здесь, а потом передать содержимое аккумулятора в шаблон, под именем peopls, не получится именно тот эффект, которого вы и добивались?

Пара мыслей помимо вашего кода:
Какова дальнейшая судьба файлов, которые вы уже обработали, вы будете их читать опять, при следующей итерации? Если файлы будут добавляться достаточно часто, то каждый следующий запрос будет работать дольше предыдущего. Может стоит еще раз подумать?
В зависимости от объема файлов и/или их количества, в особо тяжелых случаях, вы можете упереться в лимит времени ответа. Чинится это легко, но помнить об этом стоит.

В одной вкладке откройте страницу, на которую вам не удается перейти, в другой страницу, на которой стоит ссылка. Сравните, какая она есть, и какой должна быть. Возможно, что какая-то переменная не определена в контексте шаблона, и ссылка собирается некорректно. Если так, то проблема решится, как только вы отдадите шаблону все данные.
Если вы собираете ссылки вручную, то можно поправить код, чтобы она стала верной, но это неправильный подход.
Не слушайте вредных советов, используйте url в шаблонах и reverse в контролере, вместо ручной сборки ссылок. Это избавить вас от лишней работы, если вы решитесь сменить настройки вашего приложения, или переиспользовать его в другом проекте.

Вопрос снят.
Помогло явное указание z-index для контрола, к которому привязывается автокомплитер. Под пингвином все работало и без этого, а под M$ не пошло. Жаль, что я не разглядел этого в ворохе слоев раньше.
Всем спасибо за внимание.

Параметры разве не должны собираться с помощью "&"?
Я бы еще посмотрел на эту функцию, для подготовки параметров перед отправкой.

Как - то, почитал я ответы коллег, и остался разочарован. Понятно, что вопрос не простой, а очень простой, но можно и по аккуратнее в изложении. В общем, мои 5 копеек.
Любой цикл - это кусок кода, который обычно называют телом цикла, и который мы желаем выполнить несколько раз. Количество повторений может быть заданно заранее, например: цикл от 0 до 10, зависеть от данных, например: для каждого элемента массива или зависеть от значения, которое мы в теле цикла вычисляем, например: пока f(x) > 0 выполнять. По крайней мере, во всех известных мне языках программирования, есть оператор досрочного выхода из цикла.
while. Цикл с предварительным условием. Выполняется пока условие истинно. Проверка происходит до исполнения тела цикла. Если условие изначально ложно, то тело не выполнится ни разу. Если условие ни когда не станет ложным, то мы получим бесконечный цикл. Распространенные ошибки новичков, при использовании этого цикла:
- условие не зависит от переменных, которые изменяются в теле цикла, и оно всегда получается истинным
- условие ни когда не станет ложным, в силу его свойств, например: X * X >= 0 всегда верно
Пример на php:

$i = 1;
while ($i <= 10) {
    echo $i;
    $i++;
}

do ... while. Цикл с постусловием. Отличие от предыдущего в том, что тело цикла исполняется хотя бы один раз, и после этого происходит проверка условия выхода из цикла. К типичным ошибкам предыдущего вида циклов добавляется то, что этот цикл гарантированно исполняется один раз, что не всегда желательно.
В этом примере цикл отработает один раз, не смотря на то, что условие ложно:

$i = 0;
do {
    echo $i;
} while ($i > 0);

for. Чаще всего этот оператор описывает цикл с фиксированным количеством повторений. Вот так он может выглядеть, например, для php:

for ($i = 1; $i <= 10; $i++) {
    echo $i;
}

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