Mr_Floppy

count() всегда делает запрос, причём только один. len() - не всегда делает запрос. Содержимое SQL запроса count можно увидеть только через connection:

from django.db import connection
print(connection.queries)

Если нужно узнать количество объектов в выборке И итерироваться по ней - всегда используй len(), он работает следующим образом:

1. Если выборка ещё не в кэше (SQL не запрашивался) - выполняет запрос
   
2. Возвращает len() QuerySet'а
   

Если нужно только узнать количество - используй count()

перспективы есть,
но есть три варианта:
1. Совковые и гос предприятия. армия и тд, з/п до 40-60 тр в Мск СПБ. Отношение хуже некуда, привыкай сверхурочить до часу ночи по выходным. Тут может и пригодится асм.

2. Частные предприятия ориентированные на наш рынок, в столицах их нет, в регионах есть, з/п средненькая, макс 1500 долларов за 10+ лет опыта работы и знание схемотехники и технологии. как там работается незнаю. Тут си и си++ под baremethal, редко FREERTOS. про именно написание на асме лучше не заикаться - красная тряпка для них, резюме сразу в корзину! - признак жуткого дилетантства.

3. Аутсорс компании работающие в СПБ и МСК на запад, на старте з/п от 3т долларов если с опытом. тут всё шикарно, ДМС, доп выплаты, переработки правда есть, но не так много и дико как в п.1 но НУЖНО ЗНАТЬ АНГЛИЙСКИЙ ОЧЕНЬ ХОРОШО, а лучше БЕГЛО. А так же НАДО знать С++, DSP, асм полезен но только на чтение (спрашивают часто), Досконально знать gcc тулчейн, linux kernel и тд. Очень пригодится веб и джава и умения админить (не путать с эникейством). Заказчики тут мне попадались крупные, Интел, Аппл, Самсунг, Матсушита и Митсубиси, Тошиба. Да и очень рекомендуется иметь загран и отсутсвие косяков с визами.

На большинстве (всех?) современных ОС получение времени - это функция ядра. Следовательно для пользовательского процесса в userspace это требует ровно один вызов в ядро, который представляет собой syscall, то есть программное прерывание. На стороне ядра код обычно тривиальный и заключается в получении значения переменной, в которой хранится время (эта переменная инкрементируется из обработчика прерывания таймера), и возврате этого значения через sysret, то есть возврат из прерывания. Поэтому основные временные затраты сводятся к исполнению syscall/sysret и сохранению/восстановлению контекста пользовательского процесса при входе/выходе в/из ядра.
От единиц измерения (нано/мирко/милли) скорость вызова практически не зависит. Конвертация одних единиц в другие происходит на стороне пользовательского процесса, за это отвечают библиотеки и окружение конкретного языка, но эти вычисления составляют всего несколько машинных инструкций и не вносят значительный вклад общее время вызова.

В Linux существуют несколько таймеров в ядре: высокого/обычного разрешения и переводимые/непереводимые назад, но получение времени происходит через одну функцию clock_gettime как бы по-разному это не выглядело в разных ЯВУ.

В Windows стандартные механизмы GetSystemTime и GetTickCount выдают время только с миллисекундной точностью. А таймер высокого разрешения QueryPerformanceCounter предназначен только для измерения временных интервалов, его абсолютное значение не имеет смысла.

Историческая справка: В реальном режиме работы x86 до тех пор, пока BIOS владеет аппаратным прерыванием таймера и таймер настроен по умолчанию (его еще можно перенастраивать), то есть с интервалом в 55ms и частотой в 18.2 герц, на каждый тик таймера инкрементируется четырехбайтное значение по абсолютному адресу 0:046C. Так что пользовательская программа (термин процесс тут не совсем применим) может получить значение времени мгновенно простым считыванием этого значения из памяти без каких-либо вызовов.
Стоит отметить, что данный функционал не имеет никакого отношения к DOS или какой-либо ОС вообще, а прошит в BIOS любого x86-совместимого (даже современного) компьютера и действителен каждый раз при загрузке машины вплоть до момента перевода процессора в защищенный режим в момент загрузки ядра современной ОС.

Делаем запрос к ВК API
Получаем посты со стены
Выбираем только те, у которых ID больше чем у последнего опубликованного
Публикуем на сайте

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

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

А многозадачность это свойство ОС вычислять одновременно (*условно говоря) много задач (процессов и потоков) или проще говоря программ. Это дает вам возможность одновременно играть в игру и слушать музыку на своем компьютере.

* на самом деле процессор работает в последовательном режиме и соответственно на самом деле не может одномоментно вычислять более 1 процесса или потока, но так как он способен вычислять гигантское количество операций в единицу времени и быстро переключается с одного процесса/потока на другой и обратно, то часто говорят одновременно. Но и здесь стоит сделать оговорку, что многоядерные процессоры позволяют действительно вычислять несколько процессов/потоков параллельно, где каждое ядро процессора может взять на себя вычисление 1 потока или процесса в единицу времени.

Вывод. Если у вас 4-ех ядерный процессор, а ваша программа работает в один процесс с одним потоком, то ваша программа будет вычисляться всего лишь на 1 ядре. Поэтому можно создать 4 потока в одном процессе или 4 процесса по 1 потоку в каждом и тогда ваша программа смэппится на все ядра процессора и займет все его возможные мощности. В тоже время создание более 4 потоков или 4 процессов не будет иметь особого смысла, поскольку всё равно вы сможете параллельно вычислять только максимум 4 из них.

При создании любого процесса внутри него автоматически создается как минимум 1 поток. Но также вы можете самостоятельно создать и более 1 потока, если у вас появится такая необходимость.

ИМХО, расточительно делать отдельную таблицу под пол. Отлично подойдет (если не уходить в дебри человеческих отклонений):

enum Sex { 
    Male,
    Female,
    Undefined
}

bool? - тоже вариант, но читается хуже.

stackoverflow.com/questions/18424260/django-servin...

fias.nalog.ru/Updates.aspx

UPD
Дополню: КЛАДР о котором пишут в соседних ответах - это не старый формат, это другой формат, хотя и являющийся предшественником ФИАС. Оба справочника являются пополняемыми и обновляемыми, оба содержат косяки и ошибки причем как общие, так и персонально свои.
На уровне работы с регионами и городами - проблем особых нет (не считая идиотского устройства городов нашей страны, когда город может являться частью другого города находясь в десятке километров, а поселок находящийся в черте города может быть обособленным), а вот на уровне улиц/домов опечатки бывают достаточно часто.