LINUX.ORG.RU

Зачем Python?

 , ,


5

5

Обычно, ЯП - это инструмент, заточенный для решения задач в какой-то определенной сфере. У создателей ЯП была для него ЦЕЛЬ, которая наполняла смыслом бытие ЯП. Или же ЯП оказался обладателем таких характеристик, которые позволили эффективно решать определенные задачи, даже если изначально на него были другие планы. Это также объясняет необходимость существования ЯП.

Что-то низкоуровневое - Си, Rust, Ada; сервер - PHP, Go (а где-то Java, JS); клиент - JavaScript; энтерпрайз - C#, Java; скрипты для CLI - bash, lua (хотя сойдут PHP или JS); математика - R, Fortran; мобильные приложения - Java, Kotlin, Swift; начальное обучение - Basic, Pascal (можно Lisp, но лучше не стоит). Всё ясно, понятно.

А какие специфические задачи решает Python? В чём его смысл? Вот в (https://youtu.be/KnFrdzG79ak?t=532) МФТИ на информатике говорят, что Python - это классная штука, так как на нём можно всё (и в web, и в смартфон), мол универсальный. Но, имхо, это скорее минус, чем плюс. Это как швейцарский нож - может многое, но всё не очень качественно. В (https://youtu.be/bX3jvD7XFPs) MIT'e перевели обучение с эльфийского (Scheme) на Python. Ну для педагогических целей, для первокурсников, может Python и выглядит лучше. Хотя как аргумент в его пользу - ну так себе.

Пока я вижу, что в реальном мире Python (объективно) нужен для двух задач:

1. Поддержка legacy-кода, уже написанного адептами Python'а. Например, какие-нибудь скрипты для иксов, скрипты для сис.админов и т.п.
2. ML. Просто потому, что под ML были написаны нужные библиотеки (в нужном кол-ве и кач-ве) именно на Python. По неизвестным причинам написаны.

Сфера для (эффективного) применения Python'а очень мала, или мне показалось?

При этом, повсеместно говорят о популярности Python, как это модно-молодежно, его мол и учите. Закрадываются подозрения. А не является ли широкая популярность (или слухи о ней) Python исключительно маркетинговым явлением, когда ЯП, опять же по неясным причинам, проталкивают сверху? Если это так, то для чего это делают? А если не так, и он объективно эффективно решает какие-то задачи (почему его добрые люди и советуют), то объясните какие это задачи, какова целевая сфера применения Python'а, каков его смысл, цель???



Последнее исправление: Edward_I (всего исправлений: 3)

Ответ на: комментарий от RazrFalcon

Но это лишено смысла без редактирования самого байткода, который будет что-то делать с аргументом, который мы добавили. Что тоже вполне возможно, в конце концов его можно нагенерить с помощью compile.

Вообще, например, популярная ponyorm делает манипуляции с байткодом чтобы получить свою магию https://stackoverflow.com/questions/16115713/how-pony-orm-does-its-tricks

pawnhearts ★★★★★
()
Ответ на: комментарий от RazrFalcon

Конечно, бывают. Сишечка.

/0

Побыстрее этих ваших растов. А надёжность зависит от кривизны рук разраба, на которую Go накладывает серьёзные ограничения.

WitcherGeralt ★★
()
Ответ на: комментарий от anonymous

Предполагается, что мы этот open делаем вы нашем contextmanager, в __enter__. Но ты прав, он может внутри блока with нагенерить новых ссылок на этот объект, тогда хз, разве что все их удалять.

pawnhearts ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Не идиоматично, опасно и оверхед ко всему ещё.

С этим никто не спорит.

anonymous
()

А какие специфические задачи решает Python? В чём его смысл?Сфера для (эффективного) применения Python'а очень мала

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

с английским на «ты» или Вам перевести?

hibiscusM
()
Ответ на: комментарий от WitcherGeralt

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

имхо питон или что-то типа того вполне норм для курсов, где акцент идет на алгоритмы, например, а не технические детали. там борьба с указателями только отвлекает. сишечка тоже должна быть, но например для курса ОС.

pawnhearts ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Побыстрее этих ваших растов.

Емнип были бенчмарки, где жава была быстрее с. Хорошими эти бенчмарки никто не называл.

anonymous
()
Ответ на: комментарий от WitcherGeralt

python vm работает не так. Тогда у тебя у каждого блока должен быть отдельный code_object и т.п. грубо говоря.

Идея в том, что у тебя функции не должны быть слишком большие и вся хрень собирается по выходу их них.

pawnhearts ★★★★★
()
Ответ на: комментарий от pawnhearts

И тут опять вступает в дело Go.

Он проще питона в разы, ада с указателями тоже нет, хотя указатели есть, а практически классический сишный синтаксис снижает порог вхождения в любой C-подобный язык. И, что важно, компилятор и тулчейн не позволят студенту говнокодить почём зря.

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

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

pawnhearts ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Сишечка

А вот и любители постарше.

Побыстрее этих ваших растов.

4.2 же.

Go накладывает серьёзные ограничения

По сравнению с чем?

RazrFalcon ★★★★★
()
Ответ на: комментарий от pawnhearts

Что за одержимость производительностью язычка?

Есть широкий спектр задач, где это критично.

Но имхо, спор вида Go vs python лишён смысла. Ибо сравниваем тёплое с мягким.

RazrFalcon ★★★★★
()
Ответ на: комментарий от pawnhearts

Вот только сразу как заходит речь хоть о какой-то производительности, вокруг питона начинают расти горы коситылей.

Зачем это всё?

WitcherGeralt ★★
()
Ответ на: комментарий от RazrFalcon

А вот и любители постарше

Ты Кристи Бринкли видел? На 20 лет старше сишечки и всё ещё хот.

4.2 же

Да вроде бы нет пока ещё. Или уже да? Ещё недавно раст за обе щеки всасывал.

По сравнению с чем?

С сабжем.

WitcherGeralt ★★
()
Ответ на: комментарий от RazrFalcon

Оба просты для изучения и ниши сильно пересекаются. Вебня, сервисы всякие, консольные тулзы. Docker и docker-compose к примеру.

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Кроссплатформенные приложения и гуй

Не надо. Если очень нужен наколеночный гуй, то лучше убить двух (во многих случаях) зайцев, используя электрон.

Только если уже знаешь яваскрипт и веб в целом, но вообще не знаешь питон. А если не знаешь ни того ни другого, то освоить гуй на питоне всё-таки проще.

Простая встраиваемость

Лучше луа, питон жирноват и обычно оверкилл.

Синтаксис луа намного проще, но в результате луа слишком многословен, и скуден на библиотеки. Да, он меньше, и встраивается легче, но и писать на нём тяжелее.

А ещё python не sandbox-ится. Поэтому для игр, где нужен sandbox, или надо ограничивать вызываемые функции, lua подходит лучше. Но во многих случаях это не нужно, например, если я пишу плагин в gimp для liquid rescale, то мне не нужен маленький язык, мне нужен удобный язык, который легко биндится к библиотекам, читает и пишет картинки.

pynonymous
()
Ответ на: комментарий от WitcherGeralt

Сишка с GC vs нормальная скриптота. Может для бекенда и нет разницы.

RazrFalcon ★★★★★
()
Ответ на: комментарий от pynonymous

не sandbox-ится.

Занятно, раньше для этого были модули, вроде даже в stdlib. Но их выпилили из-за багов. Но варианты все-равно есть.

pawnhearts ★★★★★
()
Ответ на: комментарий от RazrFalcon

Сам я ничего не тестил, но то тестам, что видел, ещё пару-тройку лет назад раст вообще довольно тормозным был.

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

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Один из лучших для обучения

Спорно. Потом народ не врубается в самые очевидные вещи при виде нормального языка.

Тут что ни выбери, всегда найдётся другой язык (например, хаскель или эрланг), в котором потом «народ не врубается в самые очевидные вещи».

Но, да, это непростой вопрос. В двух словах и не опишешь...

При выборе «языка для обучения» учитывается много факторов. Это и количество областей с которыми можно ознакомиться, и востребованность языка по окончании обучения, и простота переноса опыта на другие языки, и даже наличие учебников на русском.

Но в конце концов всё сводится к вопросу: чему мы хотим научить — языку или программированию? Что в результате человек должен освоить — терминологию (указатели, ссылки, виртуальные функции, шаблоны и другие страшные слова) или навыки структурно излагать свои мысли в виде кода?

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

Но ты не сказал главного. Когда производительность и надёжность важнее скорости разработки, питон вне игры.

Да, но не всегда. Иногда сработает такой подход: набросали прототип, проверили, если работает быстро — задача решена. Иначе прошлись профайлером (хотя бы python -m cProfile), вынесли жручий код в отдельные функции, оптимизировали алгоритм, если стало быстро — задача решена. Если нет, но выиграть надо немного, ускорить в 2-5 раз, то расставили типы и прошлись cython-ом — задача решена. Если и этого не хватило, переписали эту конкретную функцию на си, подключили cython-ом. Лучше уже некуда.

И не приходится переписывать весь код на «более оптимальном» языке — оптимизируется только то, что требует оптимизации.

В этом, кстати, опыт на питоне помогает и в других языках — учит отделять высокоуровневую архитектуру от низкоуровневых деталей.

pynonymous
()
Ответ на: комментарий от WitcherGeralt

Не знаю как у остальных, а у меня ни разу в жизни такого не было. Разве что kate вот шалит когда отступы табами, не знаю в чём дело. Но то в венде и версия там трёхлетней давности.

anonymous
()
Ответ на: комментарий от anonymous

Оправдание твоего не отформатированного кода - это архаичный костыль из сишного конпелятора?

С «костылями из сишного конпелятора» можно форматировать как хочешь, а с некостылями пистончика можно только так, как кто-то там решил.

crutch_master ★★★★★
()
Ответ на: комментарий от no-such-file

Во-первых, пролюбить отступ сложнее, чем символ. Во-вторых, ты исключаешь, что можешь ошибиться и не там закрывающую скобку поставить? В третьих, исправить неправильный отступ можно в одно нажатие, перенести скобку — нет. В четвёртых, принудиловка относительно отступов вырабатывает привычку сразу писать красиво, а не фигачить нечитаемую лапшу. Сказки про «я пишу как я хочу» можешь не рассказывать. Либо ты пишешь только однодневки, которые даже сам потом не используешь.

mogwai ★★★★
()
Ответ на: комментарий от Deleted

Какая мешанина? Вложения отражают иерархическую структуру кода. Она должна быть табами, т.к.

  • всякие извращенцы, которым отступ в 2 или 22 пробела нужен, всегда будут довольны
  • один символ всегда лучше, чем два, т.к. исключена возможность делать везде отступ в 4 пробела, а вот на этой строчке сделать в 6, после неё отступ сделать 10 и так далее…

Лучшее подтверждения идиотизма отступов пробелами — yaml.

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

object_with_long_name.method_with_long_name_1(another_object.property1,
                                              another_object.property3,
                                              third_object.method(another_object.property2),
                                              third_object.method(another_object.property4),
                                              third_object.property5);
object_with_long_name.method_with_long_name_2(another_object.property1,
                                              another_object.property3);
object_with_long_name.method_with_long_name_3(another_object.property1);
object_with_long_name.method_with_long_name_4(another_object.property1,
                                              another_object.property3,
                                              third_object.method(another_object.property2),
                                              third_object.method(another_object.property4));

всегда читабельней

object_with_long_name.method_with_long_name_1(another_object.property1, another_object.property3, 
third_object.method(another_object.property2), third_object.method(another_object.property4), 
third_object.property5);
object_with_long_name.method_with_long_name_2(another_object.property1, another_object.property3);
object_with_long_name.method_with_long_name_3(another_object.property1);
object_with_long_name.method_with_long_name_4(another_object.property1, another_object.property3, 
third_object.method(another_object.property2), third_object.method(another_object.property4));

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

/HOLYWAR

mogwai ★★★★
()
Ответ на: комментарий от RazrFalcon

Лучше в чем? Я пробывал писать на питоне, но даже после PHP(!) ломала его куцость синтаксиса. А уж как быстро он выполняется...

Единственные плюсы бидона - есть биндинги к почти каждой собаке и «читаемость», можно читать и понимать листинги даже не зная питона

Ford_Focus ★★★★★
()
Ответ на: комментарий от oldstable

асинхронная лапша в скриптах

к счастью (для меня, по крайней мере) в ноду потихоньку завозят методы с суффиксом Sync и методы, возвращающие Promise

Ford_Focus ★★★★★
()
Ответ на: комментарий от crutch_master

Ну вот, кто-то говорил про говнокод.

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

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

А что, вот этот скрипт не выглядит как дерьмо, легкочитаем итд?

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

pynonymous
()
Ответ на: комментарий от Ford_Focus

У меня к синтаксису питона претензий нет. Для моих задач ничего лучше не нашёл.

RazrFalcon ★★★★★
()
Ответ на: комментарий от crutch_master

Тебе надо ты прикручивай. Мне и так норм.

С «костылями из сишного конпелятора» можно форматировать как хочешь, а с некостылями пистончика можно только так, как кто-то там решил.

Вот тебе и ответ, питон нужен, чтобы не делать таких говнокодеров.

anonymous
()

Печально видеть, что основной претензией к питону у многих людей здесь является плохая поддержка парадигмы стэковерфлоу-драйвен-девелопмент. Считаю, этим несчастным нужно помочь, создать новый ЯП definitely-not-a-python, который в точности python3, но со скобками.

ugoday ★★★★★
()
Ответ на: комментарий от pynonymous

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

Это бред. Серьёзно. В питоне ничего не мешает использовать одну переменную для всего.

Код на питоне автоматически получается более понятным.

Отступы не делают никакой погоды. Это меньшее, с чем могут быть проблемы. Сделай astyle в любом другом языке и всё будет норм. Проблемы возникают с больной логикой. С одной переменной на все случаи жизни. С сайд эффектами. Питон это как-то предотвращает? Ява вот предотвращает хотя бы тем, что там нет глобальных переменных, хотя всё еще можно говнокодить через поля и прокидывание какого-нибудь объекта через все методы параметром.

Да, в общем-то не так и плохо.

Потом прокомментирую это «не так и плохо».

crutch_master ★★★★★
()
Ответ на: комментарий от crutch_master

Ява вот предотвращает хотя бы тем, что там нет глобальных переменных

Пфф. В питоне скоп глобальных переменных ограничен *.py-файлом. В джаве аттрибуты видны всему *.java-файлу. Разницы ноль. Хейтеры думать вконец разленились.

anonymous
()
Ответ на: комментарий от Deleted

Да, это оно! Возьми чай и конфетку. Я забыл и сразу не вспомнил про -l, тогда даже эта моя дичь на коленке сократилась бы до:

perl -ple '$_ = join q//, reverse split //g, $_'

anonymous
()
Ответ на: комментарий от mogwai
object_with_long_name.method_with_long_name_1(
    another_object.property1,                                          
    another_object.property3,                                          
    third_object.method(another_object.property2),                                          
    third_object.method(another_object.property4),
    third_object.property5);
)

я пишу как-то так. везде только пробелы естественно.

pawnhearts ★★★★★
()
Ответ на: комментарий от Ford_Focus

И в чет куцость? На php даже orm нормальный не запилишь из-за его ограничений, чего-то типа sqlalchemy или ponyorm там просто не сделать.

pawnhearts ★★★★★
()
Ответ на: комментарий от ugoday

Я индифферентен к отступам. Однажды я посмотрел на python и вот что мне в нем не понравилось:

1. Множественное наследование. Причем Method Resolution Order между версиями python 2 и 3 поменялся. От наверняка такое изменение вызвало батхерт во многих больших проектах с большими иерархиями классов.

2. Однострочные лямбды. Если мне надо вызвать несколько методов в такой штуке ту у меня не вмещалось все в одну строку.

Церемониальные условности которые язык вынуждает соблюдать:

3. Обязательное self для обращения к членам экземпляра класса. Создается впечатление что ООП только что добавили в язык.

4. Инкапсуляция без скрытия и все эти конвенции на основе одинарных и двойных нижних подчеркиваний для обозначения области видимости.

5. Пустые __init__.py для создания пакетов, т.е. если нужно создать пакет com.example.app, то нужно создать эти файлы-маркеры в com/, com/example/ и com/example/app/.

Опять возвращаясь к впечатлению что ООП только что приделали к языку, когда на абстракциях JS начали делать ООП то там тоже возникли условности накладываемые ES3 в виде обязательного this при обращениям членам класса про который нельзя забыть и нижних подчеркиваний для обозначения видимости. Но ведь python3 появился недавно, зачем было сохранять синтаксический шум?

Aber ★★★★★
()
Ответ на: комментарий от anonymous

Нет. Открою тайну, проблема «читаемости перла» - это проблема тех, кто на перле не писал (точнее не проблема, а заблуждение). То, что какой-нибудь там javascript якобы «легко читать», или даже пайтон - это следствие изучения мало отличающихся по синтаксису языков, вот это вот семейство Си-лайк (хотя вот Си без его изучения во многих моментах не прочитаешь, «нечитаем» однозначно, ещё в детстве, много лет назад, уже имея опыт с delphi, бейсиками всякими и даже php, - от Си-кода прогорал стул, со всеми этими поинтерами, маллоками, *, &, (foo*)x и прочими void-кастами, а пописал на Си и ничего, уже мало чем удивишь). Для перла, как и для прочих нужно знать ряд ключевых моментов, специфичных для перла.

Я забыл про ключик -l и не вспомнил сразу, а писал на скорую руку, за секунды, но chinarulezz показал свой хороший пример:

perl -ple 's/^.*$/reverse/e'
А мой пример с флагом -l будет выглядеть так:
perl -ple '$_ = join q//, reverse split //g'
В регулярке //g ничего нового нет например, во всех языках такое. split от пустой регулярки - это посимвольная разбивка. reverse зеркалит список, join с пустой строкой собирает список обратно в строку. Вообще на самом деле приводя список к строке в Perl он итак его «склеит» без сепаратора, так что мой пример можно сократить до:
perl -ple '$_ = reverse split //g'
По-моему по ключевым словам интуитивно понятно что происходит. А $_ - это «переменная по-умолчанию», многие стандартные функции берут из неё что-то в качестве аргумента (если аргумент не указан явно) и сохраняют в неё свой результат (если переменная для результата не указана явно). В данном случае благодаря флагу -p $_ соответствует каждой отдельной строке. Т.е. этот код выполнится для каждой строки, где $_ - будет значением этой строки. reverse и split возвращают список, а список - это не скаляр, и записан в $_ он по-умолчанию не будет. По-этому мы явно сохраняем в $_. Переменная по-умолчанию позволяет строить цепочки обработки данных, вроде пайпов, см. https://perlmaven.com/the-default-variable-of-perl например:
while (<>) {
  chomp;
  s/foo/bar/g;
  say if /ololo/
}
Может быть заменён на:
while ($_ = <>) {
  $_ = chomp $_;
  $_ =~ s/foo/bar/g;
  say $_ if $_ =~ /ololo/
}

А если взглянуть на этот пример (изначальный):

perl -pe '$_=join q//, reverse grep {$_ ne qq/\n/} split //g, $_;$_.=qq/\n/'
Функция grep тебе уже по идее знакома из баша, она фильтрует список. ne - это сокращение/оператор для not-equal, это !=, но не для чисел, а для строк (в perl операторы на строках и на числах разделены, как впрочем и в shell например). Оператор .= есть и в других языках, см. тоже самое в php или += в javascript. Из оставшегося неразрбраного тут это q// или qq// - это эквивалент кавычкам. q// - для одинарных qq// - для двойных (в двойных возможны интерполяции переменных, как в bash например, а также экранирование, например переносов строк). Эквиваленты:
'foo' q/foo/ q{foo} q[foo] q(foo)
Для двойных:
"foo $bar" qq/foo $bar/ qq{foo $bar} qq[foo $bar] qq(foo $bar)
. Есть для для регулярок подбное. Это очень удобно, когда ты пишешь однострочник в баше, когда у тебя сам твой скрипт уже завёрнут в кавычки и экранировать кавычки - это попоболь.

anonymous
()
Ответ на: комментарий от anonymous

В джаве аттрибуты видны всему *.java-файлу. Разницы ноль

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

А по поводу глобальных перемененных вот прямо как тут в java сделать нельзя, но почти тоже самое можно добиться посредством полей в синглитонах и статических полей классов но понятное дело это бэд практис и думаю в большинстве контор безотносительно языка за это будут бдить по рукам.

Aber ★★★★★
()
Последнее исправление: Aber (всего исправлений: 2)
Ответ на: комментарий от Aber

В джава приватные поля классов видимы для внутренних и вложенных классов
Сам файл никак не определяет область видимости.

Когда я заглядывал в джаву один *.java-файл равнялся одному (внешнему) классу. Из этого следует, что поля внешнего класса доступны в любом месте файла.

В питоне равняется модулю, «глобальные» переменные — это переменные в скопе модуля. Они видны в любом месте файла.

Чел утверждал, что в джаве нет «глобальных переменных» как в питоне. Таки в джаве есть их точный аналог, а чел неправ.

anonymous
()
Ответ на: комментарий от anonymous

В питоне равняется модулю,

*файл равняется модулю

anonymous
()
Ответ на: комментарий от pawnhearts

Я сейчас посмотрел, я слегка был не прав, ну я блин не кодю на python. Оказывается на существующих проектах это изменение не сказалось т.к. python3 поддерживает legacy MRO:

Legacy: D -> B -> A -> C -> A

class A: x = 'a'

class B(A): pass

class C(A): x = 'c'

class D(B, C): pass

D.x # вернет 'a', С.x окажется скрыт

Новый: D -> B -> C -> A -> object

class A(object): x = 'a'

class B(A): pass

class C(A): x = 'c'

class D(B, C): pass

D.x # вернет 'c'
Aber ★★★★★
()
Ответ на: комментарий от Aber

Если код сверху это типа код на python2, то это old-style classes, которые были заменены на новые в python 2.2(а это 2001 код). Они были в питоне2 для совместимости, но их никто не использовал ооочень много лет. У старых классов вообще еще много отличий в поведении.

pawnhearts ★★★★★
()
Ответ на: комментарий от pawnhearts

Я думал у меня python3, я этот код тестил в python 2.7, прямо из коробки работают в интерактивном шеле оба варианта. Это значит если я напишу A вместо A(object) то привет Legacy MRO с скрываемыми членами класса? Ситуация не очень, мне кажется в команде без статического анализатора который тут же такие ошибки подчеркнет будет грустно.

Aber ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.