LINUX.ORG.RU

История изменений

Исправление emorozov, (текущая версия) :

1.2. В процессе редактирования (особенно удаления куска кода) очень легко нарушить виртуальные операторные скобки. Без подсказок редактора снова никак.

Опять-двадцать пять. Говорят те, кто не работал никогда с Python. Мы десятилетиями редактируем код на Python. И копипейстим, и удаляем блоки. Без каких-либо проблем вообще.

2.1. Он не просто медленный, как, например, VB, он – гребаная черепаха. Вообще непонятно, чем это чудовище занимается в перерывах между обработкой строк кода.

Во-первых, он не настолько уж медленный. Для интерпретируемого языка довольно шустрый. Быстрее интерпретатор сделать сложно по очевидным причинам (работать приходится с обёртками типов, как минимум, поэтому). Python, например, долгое время, а может быть даже сейчас, быстрее Ruby. С другими интерпретаторами не видел сравнения.

Во-вторых, есть очень быстрый PyPy.

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

Когда Python создавался, это было никому не нужно: ещё 20 лет после этого, в основном везде был один проц с одним ядром.

В последние годы это стало не так, но с другой стороны, треды нужны далеко не всем и не во всех приложениях. Это не какое-то универсальное решение для всех проблем.

И разработчики Python в курсе ситуации, и работают над тем, чтобы решить проблемы, возникающие из-за GIL. Да, долгое время эта проблема игнорировалась, но последние года 4 идёт плотная работа, чтобы её решить, не сломав обратную совместимость.

Исходная версия emorozov, :

1.2. В процессе редактирования (особенно удаления куска кода) очень легко нарушить виртуальные операторные скобки. Без подсказок редактора снова никак.

Опять-двадцать пять. Говорят те, кто не работал никогда с Python. Мы десятилетиями редактируем код на Python. И копипейстим, и удаляем блоки. Без каких-либо проблем вообще.

2.1. Он не просто медленный, как, например, VB, он – гребаная черепаха. Вообще непонятно, чем это чудовище занимается в перерывах между обработкой строк кода.

Во-первых, он не настолько уж медленный. Для интерпретируемого языка довольно шустрый. Быстрее интерпретатор сделать сложно по очевидным причинам (работать приходится с обёртками типов, как минимум поэтому). Python, например, долгое время, а может быть даже сейчас, быстрее Ruby. С другими интерпретаторами не видел сравнения.

Во-вторых, если очень быстрый PyPy.

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

Когда Python создавался, это было никому не нужно: ещё 20 лет после этого, в основном везде был один проц с одним ядром.

В последние годы это стало не так, но с другой стороны, треды нужны далеко не всем и не во всех приложениях. Это не какое-то универсальное решение для всех проблем.

И разработчики Python в курсе ситуации, и работают над тем, чтобы решить проблемы, возникающие из-за GIL. Да, долгое время эта проблема игнорировалась, но последние года 4 идёт плотная работа, чтобы её решить, не сломав обратную совместимость.