Питон востребован в реальной жизни? Шутить изволите?Он как раз не пригоден для работы кроме школьных лаб и мелких скриптиков и вот почему, читайте:
1) https://docs.python.org/3/library/marshal.html
2) https://docs.python.org/3/library/pickle.html
Вам будет очень трудно понять в чем тут проблема, если вы не видели никаких языков кроме питона. Если писали только на всяких скриптовых бяках, то попросите старших разъяснить что такое маршалинг и сериализация и почему питон не может ни того ни другого.
I. Питон - лучший язык для велосипедостроения.
Путь есть программа, содержащая несколько классов, объединенных некоторой общей поведенческой моделью, решающих конкретные задачи и предоставляющие интерфейс. В общем случае это библиотека. Задача: вызвать метод класса этой библиотеке по ссылке.
Казалось бы, что же может быть проще, подключай и вызывай. А вот нет. В питоне есть технические ограничения:
1) Библиотека типов должна быть написана именно на языке питон
2) Подключение должно производиться локально установленным интерпретатором питон
3) Версии должны совпадать.
Из-за этого для подключения сторонней библиотеки каждый раз нужно поддерживать обвязку которая поддерживает локальное подключение или скрывает за собой удаленный вызов процедур. Эти обвязки к известным библиотекам разной степени полноты - добрая половина всего pip. Учитывая отсутствие гарантий совместимости в рамках версий, они распространяются в виде исходного кода.
Написание обвязок - это самая скучная часть разработки ПО. В питоне же нужно писать обвязки на все, ввиду технических ограничений на маршалинг объектов при использовании библиотек, написанных на других языках.
II. Питон - это закрытый язык.
Забудем об удаленном вызове функций и процедур и перейдем к обмену данными. Питонисты вообще редко понимают разницу между вызовами по значению и по ссылке. Для них сериализация и маршалинг это одно и то же ввиду отсутствия открытого функционала по маршалингу в стандарте языка. Но если присмотреться, то и сериализация имеет серьезные проблемы:
1) Питон не поддерживает стандарты W3.org при работе с сериализацией, а использует свои протоколы
2) Питон имеет 6 несовместимых версий внутренних представлений сериализации, 3 из которых касаются только третьей ветки.
3) Питон не предполагает, что сериализация возможна с кодом программы написанном на другом языке.
Пока мир пользовался XML/XSLT/XPATH, питон 6 раз переизобретал Pickle. При этом поддержки XML для сериализации в языке питон как не было так и нет, но по традиции в pip есть штук пять библиотек разной степени паршивости добавляющих частичную поддержку XML для сериализации. Питон умеет работать только с документами-XML. Нельзя просто так взять и десериализовать объекты описанные в документах в собственную ООП-модель. Ее можно десериализовать, как документ, то есть с использованием DOM, а это другое.
Обмены данными на языке питон из-за этого предполагают также уйму рутинной работы, изобретений велосипедов. Подружить два приложения из-за этого намного сложнее. То есть там где просто подняли вебсервис SOAP и начали обмен, питону придется разбираться вручную (или через сторонние недонаписанные библиотеки). Даже сам SOAP для него может стать проблемой.
III. Питон - не кроссплатформенный язык, но зачем-то им прикидывается
Стандартная библиотека языка питон по-разному функционирует на разных ОС. zipfile, subprocess да тысячи их на самом деле. Нет переносимости по исходному коду не только между версиями, но и между платформами. На платформах отличных от Linux ситуация настолько ужасна, что старый код может перестать работать. Питон не предоставляет стандарта. Он не обозначает какие части стандартной библиотеки являются кроссплатформенными и не пытается добиться паритета функционала.
Такое отношение к стандарту языка в итоге генерирует огромное количество дополнительной работы. Разработчику кроссплатформенного приложения нужно писать обвязки и проверки платформы, на которой запущен код.
IV. "Сообщество" питонистов - общество защиты велосипедов с квадратными колёсами.
"Зачем тебе нужен XML, когда есть JSON", "Зачем тебе нужен SOAP, когда есть REST"
" - У нас в языке это делается не так
- А как?
- А никак тебе вообще это не надо"
И другие умопомрачительные истории общения... Питонисты не понимают, что REST - это архитектура, которая крайне не удобна для потоковой передачи сериализированных объектов между приложениями. В основном, потому что не знают таких слов. Из-за этого крайне трудно найти информацию по задачам сложнее чем написание скрипта, подключающего 5 библиотек, из которых 4 - обвязка над библиотеками на другом языке. Причем они искренне обижаются и злятся, когда сами не могут решить задачу сложнее.
За последние годы питонисты сделали все возможное чтобы довести до ума сериализацию JSON. Целиком они его не поддерживают, конвертацию JSON <-> XML описываемую свежими стандартами они тоже не могут, но хотя бы что-то есть. Не понятно зачем до этого 5 раз переизобретать велосипед Pickle было. Сидели бы и работали в JSON, раз не можете в XML. Но нет...
Культура сообщества Питон - это культура NIH и переизобретения велосипедов с последующей обороной кривой рамы и квадратного колеса. Заявишь, что тебе нужно интегрироваться с приложением и быстро выдать XML-объекты - получишь перепиши всё на питоне. Нужна тебе поддержка кодировок, это они сами в твоей ОС виноваты, что она не Linux с UTF-8 (хотя сами сидят всё в UTF-32 конвертят). Причем это диктуется самим языком. Любая интеграция со сторонним кодом в питоне предполагает бесполезные упражнения в написании обвязок. Там настолько много этой рутины, что люди забыли или не знают, что так быть не должно. Вон там выше прыгал Леголас, рассказывавший историю:
> без обид, но может разработка -- это просто не её/ваше? на питоне писал в том числе (по криптографии), каких-то сложностей не возникало
Эталонный питонист из парижской палаты меры весов же...
1. Как всегда никаких сложностей, он один умный, а все тупые.
2. Назвал написание обвязок разработкой по криптографии.
Питонисты они хуже по квалификации разработчиков 1С. То же самое "Если-Тогда-КонецЕсли" и написать обработку над COM-библиотечкой. Но есть 3 отличия:
1. Они могут в XML и обмен данными
2. Они решают бизнес-задачи быстрее питонистов с тем же качеством и даже большей производительностью результата
3. Сообщество не страдает манией величия.
