Игорь, Я не знаю где там профанация. Вполне себе ООП язык, продвинутее некоторых других ООП языков.
Большинство сравнений языков на этом пункте даже не останавливаются, потому что тут и обсуждать толком нечего.
Большинство сравнений концентрируются на динамической типизации, так как это считается основной причиной ошибок.
Честно говоря, я не знаю. В своей практике я бы не сказал, что основная причина ошибок — динамическая типизация. Но так как я уже лет 15 пишу исключительно на Python, может быть у меня изменилось бы мнение, если бы я начал писать на языке со статической типизацией.
Я думаю, что скорее и проще войти в Python. Хотя бы потому что язык проще, установить просто, много отличных учебников для начинающих, включая тот, что входит в поставку языка.
Architecktor13347, это понятно, но проблема со скриптом явно не в stty. К тому же, в рамках Dockerfile эта директива вообще не имеет никакого значения — команды в Dockerfile определяют структуру контейнера, настройки терминала вообще не из этой области, и ни на что данная команда в Dockerfile повлиять не может.
Если уж на то пошло, тогда надо в контейнере запустить shell, а в нем уже вручную выполнять stty.
разница в них не в синтаксисе, а в том что Ява это 100% ООП и она строго типизирована
Вам надо быть внимательнее с терминами. Python тоже 100% ООП и тоже строго типизирован. Отличие Python от Java в том, что в Python динамическая типизация, а в Java — статическая.
Замазывать fingerprint ключа на скриншоте не нужно — это не секретная информация, наоборот.
Вам следует хорошо изучить, что такое ключи ssh в частности, и криптография на открытых ключах в общем.
В данном случае, полагаю, что ваш ssh не видит тот ключ, который вы загрузили на GitHub. Не видит, потому что он либо лежит не в том месте, где ssh может его найти, либо вам надо использовать ssh-agent.
Действительно же, интернет-магазинов написан вагон и маленькая тележка. Можно выбирать на любой вкус: по языку программирования, по используемому фреймворку, по красоте кода, по удобству, по распространенности, по поддержке платежных систем.
Я в жизни раз 15 сталкивался с тем, что меня просили помочь доделать магазин, или исправить ошибки в каком-нибудь магазине, и т.п.
Каждый раз, когда я открывал код этих самописных магазинов, у меня волосы вставали дыбом. Даже написать магазин — это непросто.
Магазин — это не только каталог и корзина (хотя по-хорошему даже эти вещи грамотно непросто сделать). Это и доставка, и интеграция с платежными системами, и черт со ступой. И все это грамотно, быстро, расширяемо (чтобы через полгода можно было добавить новую платежную систему, или новую систему доставки) написать может только очень опытный человек. А ему проще будет взять уже готовый магазин, натянуть шаблон, да подкрутить параметры.
Писать магазин имеет смысл только как учебный проект, но никак не за деньги для реального использования.
J_K, внутри библиотеки можно использовать относительные import. В коде, использующем библиотеку придётся переименовывать. IDE, PyCharm, например, может переименовать автоматически. И вообще такие перемещения в жизни случаются редко и проблемой не являются.
11000 страниц это ничто даже для самого медленного языка. Затраты времени на попытку вкорячить многопоточность явно будут в несколько раз выше, чем возможный выигрыш в скорости.
J_K, А в чем смысл таких исходников. Нормальные люди уже лет 15-20 так не делают. А библиотеки, написанные непонятно кем более 15 лет назад или неприменимы в современных условиях, или просто настолько плохи, что никому не нужны. Я пока исключений почти не видел, хотя это мой личный опыт, конечно.
Ну а если действительно что-то ценное, то вижу два варианта:
1) взять исходники, красиво оформить, выложить на GitHub и PyPI, для себя и для других
2) взять исходники и положить в корень своего проекта
Система импорта модулей и пакетов Python довольно проста и многократно описана. Если вы хотите положить их в какую-то внутреннюю папку, то, например, создаете папку vendor, кладете в нее библиотеку, и добавляете каким-либо образом папку vendor в переменную окружения PYTHONPATH или список sys.path в python (например, в файле конфигурации).
J_K, Любой правильно оформленный пакет python кода, да. Если вам надо изменить чужой код, то вы форкаете репозиторий на GitHub, делаете изменения, тестируете, создаете Pull Request авторам кода, они его мержат, выпускают новую версию, которую можно установить через pip.
А еще pip может устанавливать пакеты напрямую из git/mercurial/svn репозитория.
И в любом случае, код, который устанавливает pip, лежит в читаемом виде в virtualenv. Если так уж действительно надо что-то в нем быстро изменить, достаточно его найти в virtualenv и изменить все что надо. Естественно, что при пересоздании virtualenv или при обновлении пакета, правки будут потеряны. Но это и правильно. Тащить vendor зависимости напрямую в дерево исходников своего проекта — в 99% огромная ошибка.
При включении двухфакторной аутентификации, все сайты выдают список резервных паролей, которые я тут же либо сохраняю в зашифрованном файле, либо печатаю из браузера и прячу в надежном месте.
Алексей Жданкин, Нет нелогичности. Практически любой язык программирования обрабатывает команды сверху вниз. Объявление переменной начинает действовать начиная с того места, где она объявлена.