Сергей Протько

Гуевый постфиксный калькулятор... У меня это была одна из первых лабораторных работ... обратная польская запись и т.д.

Даже после этого я не могу сказать, что знаю джангу.

Мде... а вы надеялись что после одного, предположу что довольно простенького проекта вы сможете это сказать? Да и знать надо не джангу а пайтон.

Что до вашего уровня... Из того что вы описали - ниже чем джуниор но не полный ноль. Возможно вы описали не полностью но...

как работает DNS

И как же? Не приблизительно, а хотя бы основные моменты непосредственно реализации. Я серьезно - опишите. Ибо информации о себе вы мало написали. Только если все же решитесь описать - не подглядывайте в вики или другие источники.

что такое веб-страница

И что же это? Как можно более кратко.

бывает табличная и нетабличная вёрстка

Эх... когда-то так и было... было только табличное vs нетабличное... сейчас все немного сложнее. Табличной верстки болье нет. Это как табу. Только при верстке писем еще ее используют потому что других вариантов не особо много порой.

дал знаний о типизациях

знаний возможно, но видимо не понимания...

if (i < infixExpression.Length && OperatorPriorities.Keys.Contains(infixExpression[i] + ""))
...
OperatorPriorities[op + ""] <= OperatorPriorities[operatorsStack.Peek() + ""]

Да и уж простите, но "типизация" это... ну настолько базовая штука что лучше бы вы не акцентировали свое внимание на этом.

По поводу JS:
setTimeout("digitalWatch()", 1000);

Что можно сделать с собой? Глядя на ваш код я так понимаю с такой аббривиатурой как DRY вы еще не встречались... Рефакторинг для вас так же пока пустой звук. Что до фреймворков и языков вы правы. Фреймворки это хорошо, но язык тоже надо знать. Вы не сможете по сути писать клиентский код (код который использует библиотеки и фреймворки и реализует собственно бизнес логику приложений) не зная языка. Так же у каждого языка своя философия. У Python она одна, у Ruby другая.

С точки зрения архитектурных решений разница между языками практически невилируется. Различаются особенности имплементации связанные с философией языка, но в целом все примерно то же самое.

с передачей массива post

Почитайте на википедии что такое HTTP и что такое тело запроса. То что вы видите в PHP под этими суперглобальными $_SERVER/$_POST/$_GET/$_FILES и т.д. это все благодаря такой чудной вещи как SAPI (Server Application Programming Interface). То есть заболтивый PHP берет ваш HTTP запрос (который ему дали обработать WEB-сервера, апач тот же или nginx или еще кто) и вызывает соответствующее SAPI. То есть если у нас mod_php апачевский, то там все чуть по другому (SAPI для PHP много всяких разных). Если у нас php-fpm, то у нас там самый что нинаесть запрос, который нам проксировал какой nginx или тот же апач. Этот самый SAPI берет заголовки запроса и распихивает все по суперглобальным массивам. Он берет заголок с куками и распихивает его в $_COOKIE или видит что у нас POST запрос и он помечен как multipart/formdata и разбирает запрос, выковыривает файлики и сохраняет на диск заполняет массивы $_POST/$_FILES. Скажем если чувак отправит запрос с Content-Type: application/json (что модно стильно молодежно для мобильных клиентов) то PHP SAPI разобрать его будет не в состоянии и вам придется брать тело запроса и разбирать его самому.

Работа вашего скрипта происходит только ПОСЛЕ того как SAPI все подготовит. а htaccess влияет на работу только до того как SAPI начнет работу, так что никаких POST массивов и т.д. Только HTTP запросы.

Редиректы намного интереснее, так как это результат запроса. Ну то есть... у него нету тела. нет возможности сохранить тело запроса (ну как... есть... но клиент тоже это должен уметь и одним htaccess тут не обойтись) так что при редиректе сохранить и передать на новый урл исходные данные уже не выйдет. То есть можно, но повторюсь - это должно быть реализовано с двух сторон и тогда это не совсем редирект а больше похоже на то что вы отправляете форму двумя запросами. Один - узнает куда слать данные формы, второй отправляет.

Такие дела.