Зачем Python?

Для := как раз таки неплохая.

Например:

if v := dict_.get(key):
   pass
# а тут v уже не нужно

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

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

Замерь с %timeit в ipython, оверхед должен быть эпичным.

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

/0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сишечка

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

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

4.2 же.

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

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

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

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

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

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

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

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

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

4.2 же

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

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

С сабжем.

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

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

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

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

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

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

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

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

Это когда Go был быстрее раста? Вы ничего не путаете?

С сабжем

Ну разве что с питоном.

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

не sandbox-ится.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust-go.html ?

https://bitbucket.org/ewanhiggs/csv-game ?

https://github.com/kostya/benchmarks ?

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

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

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

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

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

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

• всякие извращенцы, которым отступ в 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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);
)

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

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

Я индифферентен к отступам. Однажды я посмотрел на 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 появился недавно, зачем было сохранять синтаксический шум?

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

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

perl -ple 's/^.*$/reverse/e'

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

perl -ple '$_ = reverse split //g'

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/'

'foo' q/foo/ q{foo} q[foo] q(foo)

"foo $bar" qq/foo $bar/ qq{foo $bar} qq[foo $bar] qq(foo $bar)

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

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

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

Method Resolution Order между версиями python 2 и 3 поменялся.

В каком месте?

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

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

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

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

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

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

Я сейчас посмотрел, я слегка был не прав, ну я блин не кодю на 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'

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

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