Zanak

А зачем метакласс? Чтобы закрепить интерфейс, достаточно породится от абстрактного родительского класса. А для постройки конкретного класса - шаблон "фабрика" вам в помощь.
Как вариант - можете поиграться с importlib и грузить модули по имени, в стиле а-ля плагин.

Описание объектов, как языковая конструкция, имеет 2 предназначения.
Объекты, как способ организации кода. Мы в одном месте помещаем все данные и функции по их спользованию, относящиеся к одной функциональной части приложения. Синтаксис объявления объектов логично изучить где - то после синтаксиса описания функций.
Объекты, как способ проектирования сложных приложений, вы будете осваивать позже, когда синтаксис совсем освоите. Первые, с чем, скорее всего, познакомитесь будут шаблоны проектирования. Шаблоны - это типовые способы использования большого количества разных объектов. Многие web фреймворки реализуют известный шаблон MVС, который предлагает разделять приложение на части (M - model, здесь все для работы с данными, V - view, здесь все для отображения данных модели, C - controller, это тот, кто использует модель для получения данных и view для его правильного отображения, например, в виде json, вместо полноценной страницы, в ответ на запрос пользователя). Использование шаблона для построения приложения не ограничивает нас в использовании других шаблонов для его частей. Например ORM, популярный шаблон по работе с БД. Самому вам врядли придется его реализовывать, но вот использовать чужие реализации, почти наверняка. Со временем вы научитесь не только выделять типовые шаблоны в задаче, при проектировании решения, но и в коде ваших коллег, для анализа не только каждой отдельной функции, но и устройства приложения в целом.

Каждый фреймворк имеет свое комьюнити, которое будет топить за него.
Единственное отличие джанги от многих, если не всех, фреймворков - это наличие админки из коробки (на мой взгляд - достаточно типовой админки, и если ваш проект подразумевает широкие возможности для администрирования, то лучше этот момент не рассматривать). Если админка не актуальна, например, вы пишите чистый api и убираете всю отрисовку на сторону клиента, то здесь выбор сильно расширяется и flask с django становятся одним из возможных вариантов.
Мегаглобальных различий между сабжевыми фреймворками по удобству, наличию информации, готовых модулей, или отзывчивости комьюнити в общем - то нет. Говорят, что flask быстрее, но сам не мерил, поэтому наверняка сказать не могу.
Выбирайте что вам ближе, и более подходит для решения именно вашей задачи и вперед.

Для ОС почти нет принципиальной разницы между процессом и потоком. При создании процесса происходит выделение нового куска памяти, при создании потока - это не обязательно происходит, поток имеет доступ к памяти родителя, процесс нет. Тоесть, в контексте вопроса можно ограничится разговором о потоках.
Потоков может быть столько, сколько позволяет память, даже на однопроцессорной и одноядерной железке.
Активность потоков может управляться на нескольких уровнях. Во первых, ОС может в любой момент тормазнуть исполнение потока. Даже если этому и можно помешать, врядли это легко, да и врядли нужно это делать. Среды исполнения, иногда, позволяют указать, сколько потоков запустить для исполнения программы. Например среда исполнения erlang или go позволяет программам создавать не дорогие потоки ОС, на создание которых уходит масса времени, а более легкие, жизненным циклом которых сама среда и управляет. Происходит отображение N потоков программы на M потоков ОС, которые запрашиваются один раз, при старте.
Поток может находится в одном из состояний: спит - когда планировщик его остановил, активен - когда поток получил управление, заблокирован - когда поток ждет какое - то событие или окончание какого - то действия, например прихода данных по сети, ошибка - когда происходит обработка ошибки или освобождение ресурсов и смерть потока.
Вопрос оптимальности создания более одного потока/процесса всегда следует рассматривать в контексте конкретной задачи. Даже при неблокирующем обмене данными между потоками, как минимум, переключение потоков, если речь не идет о количестве потоков меньше или равном количеству присутствующих ядер, имеет свою цену по времени. Подозреваю, многопоточная программа начинает выигрывать у однопоточной, когда количество потоков, которым надо исполнятся паралельно не превосходит количество доступных ядер. Как только потоков становится больше, в дело приходится вступать планировщику, и естественно, он работает не мгновенно.
Вопрос оптимальности архитектуры тоже, на мой взгляд, не имеет общего ответа. Для вычислительных задач может оказаться сравнимо, использовать один двухядерный процессор, или материнку с поддержкой 2 процессоров, а, например, для запуска веб сервера и БД к нему вообще лучшим вариантом может оказаться два независимых компютера.

Не может найти имя для открытия соединения. Проверте наличие имени в DNS.

Если это

If event.text.lower() == ‘Промокод’:
    ...

копипаста из вашей попытки решить вопрос, то условие ни когда не сработает.
По api вконтакте не специалист, но правдоподобный ответ легко гуглится.

Не очень понял, при каких обстоятельствах возник этот кейс, поэтому вопросы:
- расширить класс X до класса N разве не означает, что N является потомком X?
- в методе handler родитель создает инстанс потомка, вы уверены, что это правильно?

Здесь, на мой взгляд, напрашивается наследование или инкапсуляция.
Если CmdHandler расширяет Server, то можно использовать наследование, утащив общие методы и данные в родительский класс.
Если классы предназначены для взаимодействия, и их функционал не пересекается, то, я бы, посмотрел в сторону передачи инстанса обработчика конструктору сервера или отдельному методу регистрации в инстансе.

zip забыли :)

l1 = [1, 2, 3, 4, 5, 6, 7]
l2 = [5, 4, 8, 3, 7, 8, 9]
l3 = [l * r for (l, r) in zip(l1, l2)]
print(l3)

Для простых случаев подойдет localStorage, но, что легко создается, легко же и отламывается.
Для более сложных случаев надо смотреть, какие требования предъявляются.
Например, если пользователь перед отправкой сообщения авторизуется, то, самое надежное - это, например в редиску, положить информацию, что пользователь такой - то недавно уже постил в такой - то ветке. Время жизни ключа будет определять длительность запрета на повторное комментирование.
Для случая, когда пользователь может оставаться неавторизованным - надо подумать. Что точно стоит заблокировать - это прямой заход на форму по ссылке. Необходимость запрашивать несколько страниц с сайта, да еще в определенном порядке - это хотя бы немного осложнит жизнь потенциальному спамеру.

Мы перекладываем элементы из Items в Newitems, при условии, что они прежде не встречались (done = false). Чтобы заполнить требуемую табличку нужно знать содержимое Items, потому что оно может быть и [1, 1, 1, 1], тогда в результате получим NewItems = [1], а может и [1, 2, 3, 4], тогда он будет перенесен целиком.
И таки да, если я правильно понимаю псевдокод, то ошибок в нем нет.

Если я правильно понял вопрос, то ваша проблема здесь:

figures = {'1': triangle(point=point, angle=0, length=200), '2': square(point=point, angle=0, length=200),
           '3': pentangle(point, angle=0, length=100), '4': sixangle(point=point, angle=0, length=100)}

Вы вместо ссылки на функцию сохраняете результат ее вызова, и так для каждого ключа.

Почитал ответы коллег, и решил вставить свои 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 не пишу.