Руслан Гильфанов

Потому что вот.
Вы можете зайти в папку python/Lib и открыть файл datetime.py < именно его вы и импортируете. А в нём самом просто вызываемые методы. Да, там есть класс datetime, но тут действует правило:

The naming convention for functions may be used instead in cases where the interface is documented and used primarily as a callable.

Любой язык годится для больших проектов. Что не годится так слабые программисты, отсутствие архитектуры и автоматизации

Не, не правда. 99% библиотек для Python написано на Python. На Сях пишутся только критичные к скорости выполнения и расходу памяти. А ещё бывает, что для исходно Сишной библиотеки, ставшей популярной, пишут обвязку на Python, так как это относительно просто позволяет заимствовать профит.

На устройстве вы можете использовать только SQLite.

Да, является плохой практикой, хотя многие ленивые жопы считают, что юзеры без js должны пойти лесом.

Что делают в случаях, когда приложение или просто сайт не может нормально функционировать без джаваскрипта?

Закрывают вкладку и идут на другой сайт, например?

отправить невалидные данные на зло

Конечно же, на сервере проверки обязательны.

Есть конечно сервисы, которые без js не могут работать в принципе. Карты, или гугловские таблицы, например. Тут уже придется либо включать js либо пользоваться отдельными приложениями.

Данным с клиента обычно не доверяют и проверяют на беке

К сожалению, поддержкой юзеров с отключенным жс мало кто занимается

Видали и страшнее. 4 из 10.
Из минусов:
del не нужен. Сборщик мусора справится с очисткой.
Используйте with для открытия и зактрытия файлов.
Не то что бы структура очень сложная, но какие-то части можно бы вынести в отдельные функции. Это лучше бессмысленных коментариев типа #Print.
Разный стиль именования. CamelCase и snake_case для переменных
Смешивание " и '
Из плюсов:
Спасает то, что код простой.
Осмысленные имена переменных.
Какая-то структура.

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

Для начала -- добавить remote в репозиторий на другом компе:
git remote add <имя remote> <URL>
Если история на github совпадает с локальной историей, просто короче, то можно сразу пушить:
git push <имя remote> <имя ветки>
Если нет -- надо выкачивать и мёржить:

git fetch <имя remote> <имя ветки>
git merge <имя remote>/<имя ветки>
<магия разрешения конфликтов>

после чего можно пушить обратно.

Чтобы каждый раз не обращаться к БД, нужно использовать кэширование. А чтобы сохранить возможность горизонтального масштабирования сайта, кэширование организовывать не в памяти процесса, а на чём-нибудь типа memcached.

Не получится у вас с помощью многопоточности задействовать несколько ядер.

А ошибка связана с тем, что метод map в первом параметре принимает ссылку на функцию, а не результат её выполнения.

Для создания highload проектов(без разницы соц сети или нечто другое) подойдет любой стек, потому что умение справляться с высокими нагрузками достигается путем горизонтального масштабирования, позволяющего равномерно распределять нагрузку между серверами. А на каком языке и фреймворке написан бэкенд не имеет вообще никакого значения. Что касается конкретно python - например инстаграм написан на нем(python + django), думаю этого и без всяких слов должно быть достаточно для понимания, что python более чем пригоден для таких задач)

Насколько я помню, это требование утратило свою актуальность с версии Python 3.3. Лутц, вроде, об этом писал. Правда, так как я стараюсь читать самые свежие издания и в оригинале, моя настольная версия книги - 5-е издание 2013 года, последнее на текущий момент.