Издание InfoWorld опубликовало (http://www.infoworld.com/d/application-development/van-rossu... интервью с Гвидо ван Россумом (Guido van Rossum), великодушным пожизненным диктатором (http://ru.wikipedia.org/wiki/BDFL) проекта Python. В интервью затрагиваются такие темы, как Python 3, совместимость с прошлой веткой, особенности реализации глобальной блокировки GIL (Global Interpreter Lock), динамическая и статическая типизация, важность производительности языка.
Отдельный интерес представляет попытка разобраться в причинах возникновения критики, указывающей на низкую производительность Python, на которую обычно Гвидо ван Россум реагировал утверждением, что всё что он пытался реализовывать на Python работало достаточно быстро. По мнению Гвидо ван Россума, подобная критика рождается из-за неумения подобрать должный инструмент для решаемой задачи и провести надлежащую оптимизацию. Python позволяет существенно сократить время разработки сложных проектов, при этом, как правило, в ситуации недостаточной производительности достаточно выделить основные узкие места и реализовать их в виде функций или модулей, написанных на языке Си или Си++. Обычно, для большинства выполняемых приложением задач производительность языка не критична, поэтому нет смысла пытаться весь проект переписать на более быстром языке, когда можно реализовать на таком языке только отдельные части, для которых действительно важна высокая производительность.URL: http://www.infoworld.com/d/application-development/van-rossu...
Новость: http://www.opennet.me/opennews/art.shtml?num=33379
Не понятно какую производительность он подразумевает...
Быстроту сдачи проекта или производительность кода...
О производительности исполнения естественно (:То что со скоростью разработки все в порядке и так всем понятно.
Не всем
"Работало достачно быстро" чтобы втюхнуть заказчику. Зачем усовершенствовать, если можно продать и так...
"выделить основные узкие места и реализовать их в виде функций или модулей, написанных на языке Си или Си++.", если заказчик недоумевает.
"неумения подобрать должный инструмент для решаемой задачи и провести надлежащую оптимизацию." и не надо ограничивать себя только написанием кода... Можно и другие инструменты найти и провести оптимизацию не только кода.
Так и запишем: Вопрос производительности на повестке дня у Python девелоперов не стоит.
Это интерпритатор с динамической типизацией. Вопрос производительности там вообще не стоит.
> Это интерпритатор с динамической типизацией. Вопрос производительности там вообще не стоит.У всех интерпретируемых языков типизация не может быть статической по определению, так что не совсем понятно, как динамическая типизация относится к производительности питона относительно других интерпретируемых языков (а сравнивать интерпретируемый язык с компилируемым по производительности — моветон, ибо первые и так предназначены для использования в случаях, когда производительность не так важна, как другие преимущества языка). Куда более важно, что в питоне используется медлительная стековая виртуальная машина, а не шустрая регистровая — т.е. производительность динамического и строгого питона будет хуже, чем производительность еще более динамической (в силу нестрогости) Lua.
> У всех интерпретируемых языков типизация не может быть статической по определению,Какому еще определению? Ну-ка поясните, какое такое определение запрещает интерпретаторам оперировать статическими типами.
Есть ЯП, которые могут быть компилируемыми и интерпретируемыми одновременно, так работают некоторые реализации Lisp. Они компилируют код, который целесообразно компилировать, и в бинарь добавляют интерпретатор для кода, который будет интерпретироваться на ходу.
> Это интерпритатор с динамической типизацией. Вопрос производительности там вообще не стоит.во-первых, это компилятор + виртуальная машина. во-вторых, js тоже язык с динамической типизацией. давай померяем, что быстрее: любой современный движок js или современный гвидобейсик?
> типизацией. давай померяем, что быстрее: любой современный движок js или современный
> гвидобейсик?
> http://mrjoes.github.com/2011/12/15/sockjs-bench.htmlУгу, при том там почему-то фигурируют ограниченные реализации "гвидобэйсика" о которых САБЖ вообще не упомянул даже. А с полной референсной реализацией забенчить зассали, как обычно. Только вот простые смертные эти cpython и прочие pypy-цы видят только на картинках и это вообще так, какие-то демки технологий. Тогда как JS движки пилят на полном серьезе по всем понятным причинам ;)
>> http://mrjoes.github.com/2011/12/15/sockjs-bench.html
> Угу, при том там почему-то фигурируют ограниченные реализации "гвидобэйсика" о которых
> САБЖ вообще не упомянул даже. А с полной референсной реализацией забенчить
> зассали, как обычно. Только вот простые смертные эти CPYTHON и прочие
> pypy-цы видят только на картинках и это вообще так, какие-то демки
> технологий. Тогда как JS движки пилят на полном серьезе по всем
> понятным причинам ;)"CPython — наиболее распространённая, эталонная реализация языка программирования Python. CPython является интерпретатором байт-кода, написан на C. Разработка CPython ведётся группой разработчиков под руководством создателя Python Гвидо ван Россумом и является программным обеспечением с открытым исходным кодом." Гвидо ван Россум не на полном "серьезе" пилит свой проект? Хотя бы с матчастью ознакомился бы перед тем как в обсуждение соваться, а то стыд и срам.
Сразу видно - спец по питону) CPython и есть референсный
> http://mrjoes.github.com/2011/12/15/sockjs-bench.htmlи что это за ерунда? я где-то предлагал мерять скорости сокетов? или эффективность реализации фреймворков? O_O
я предлагал мерять производительность движков. ты вообще в курсе, чем это отличается от измерения производительности фреймворков, нет?
впрочем, вопрос риторический, ты же питонист, судя по всему.
>> http://mrjoes.github.com/2011/12/15/sockjs-bench.html
> и что это за ерунда? я где-то предлагал мерять скорости сокетов? или
> эффективность реализации фреймворков? O_O
> я предлагал мерять производительность движков. ты вообще в курсе, чем это отличается
> от измерения производительности фреймворков, нет?кому интересна абстрактная производительность в вакууме? есть задача - есть решение.
Скорость JS во многих тестах недалека от скорости компилируемых ЯП. А задача вполне возможно криво реализована на JS. Другая задача, другой программист и мы получим другой результат. Если вы не в курсе, иногда некоторые крутые перцы и на C или ассемблере городят чушь редкую, и их подделку скрипт на VisualBasic обгонит:) Так-что, как минимум программист должен быть одновременно одинаково опытным в работе с обоими ЯП.
Вы разработчикам Дропбокса это скажите.
> Вы разработчикам Дропбокса это скажите.Я лучше скажу это разработчикам ланчпада, стабильно икающего таймаутами бэкэнда после каждого релиза. То-есть фронт живой, а вот бэк на этом вашем питоне и подыхает как раз. Что порядком бесит. Как впрочем и значки в трее на 20 метров потому что видите ли их величествам приперло сраный диаложек и 2 значка на питоне накорябать.
Проблемы ланчпада не проблемы Python. Вот Гитхаб на рельсах, а они эталон торможения на бэкэнде, но ничего прекрасно себе работает.
> торможения на бэкэнде,А я разве говорил что мне нравится скорость работы ланчпада? Он вообще-то тот еще тормоз. А чтоб совсем хорошо - еще и HTTPS принудительный (+ еще несколько раз по roundtrip time, что на быстром интернете заметно, вообще-то).
> но ничего прекрасно себе работает.
Да, недавний эпический коммит прямо в реп рельсы был прекрасен в своей непосредственности. Исправить баг прямо через его использование - EPIC WIN! :)
> Да, недавний эпический коммит прямо в реп рельсы был прекрасен в своей непосредственности. Исправить баг прямо через его использование - EPIC WIN! :)В рельсе никто ничего не исправлял и не мог исправить, потому что никаких ошибок не было. Рельса имеет несколько вариантов ассайнментов, включая черные и белые списки. То что ребята из Гитхаба не воспользовались никаким их большая ошибка.
>> Вы разработчикам Дропбокса это скажите.
> Я лучше скажу это разработчикам ланчпада, стабильно икающего таймаутами бэкэнда после каждого
> релиза. То-есть фронт живой, а вот бэк на этом вашем питоне
> и подыхает как раз. Что порядком бесит. Как впрочем и значки
> в трее на 20 метров потому что видите ли их величествам
> приперло сраный диаложек и 2 значка на питоне накорябать.Тебе денег не хватает на планку оперативной памяти или это совковая жадность, бессмысленная и беспощадная? Или ты ни разу не использовал софт на Java? А ведь там тот же функционал отжирал бы в несколько раз больше памяти. И да, как же задолбали нытики, которые возмущаются тем, что кто-то делают не так как им хочется. Если такой умный, то возьми и сделай сам!
а я вот не использовал «софт на java». и докупать память только потому, что кто-то решил, что лучше знает, как мне тратить мои деньги — считаю как раз нищебродством «того парня»; ведь это именно нищеброды привыкли указывать другим, как тем распоряжаться *своими* деньгами.
Скорее, тут речь просто о быдлокодерстве =)
Я постоянно использую Java. И мне не жалко сложным и быстрым программам вроде NetBeans отдать немного оперативы. А вот Python ещё и проц нагружет, он же тормозила. А проц - это святое. В общем, компилируемые ЯП, и JS - лучше Python будут. В разы. Для серьёзного ПО, подделия и аплеты для Gnome можно и на Python лепить. Только вот Gnome 3 к JS тяготеет. С чего бы это?
Вот странно, вроде в тестах там всяких питон особо не сливает, мини скриптики тоже хороши, но как только что-то глобальное на нем рождается - так еле шевелится.
> Вот странно, вроде в тестах там всяких питон особо не сливаетНе сливает чему? Другим тормозиловам? Интерпретер не может быть быстрым по ежу понятным причинам.
Зато интерпретатор может быть медленным: http://tspycher.com/2012/01/performance-test-python-perl-php.../Из личного: в момента загрузки (старт скрита, к примеру) ни перл, ни пхп, ни жаба не грузят систему так как грузит пидон. Ужасно бесит! ПРОСТО БЕСИТ!!!
> Из личного: в момента загрузки (старт скрита, к примеру) ни перл, ни
> пхп, ни жаба не грузят систему так как грузит пидон. Ужасно бесит! ПРОСТО БЕСИТ!!!Сравнили одни тормозилки с другими тормозилками. Как мило. Наверное именно поэтому к php есть полно акселераторов, а фэйсбук вообще родил hiphop, перегоняющий пых в си++, получая +100 к скорости.
Акселераторы ускоряют интерпретатор? Вау!
> Акселераторы ускоряют интерпретатор? Вау!Извините, какойнить hiphop заменяет интерпретацию компиляцией :). Отсюда и разница.
> Зато интерпретатор может быть медленным: http://tspycher.com/2012/01/performance-test-python-perl-php.../идиотское сравнение и не более. в случае java львиную долю времени занял старт jvm.
можно было взять gcj и скомпилировать в нативный код.> Из личного: в момента загрузки (старт скрита, к примеру) ни перл, ни
> пхп, ни жаба не грузят систему так как грузит пидон. Ужасно
> бесит! ПРОСТО БЕСИТ!!!у меня не грузит. что я делаю не так? ну и если грузит: вы бы хоть выхлоп truss/strace привели ;)
> идиотское сравнение и не более. в случае java львиную долю времени занял старт jvm.Это в принципе тоже роялит. Ждать то придется. Хотя в случае замера именно скорости работы кода это все-таки похоже на удар ниже пояса.
>> идиотское сравнение и не более. в случае java львиную долю времени занял старт jvm.
> Это в принципе тоже роялит. Ждать то придется. Хотя в случае замера
> именно скорости работы кода это все-таки похоже на удар ниже пояса.повторюсь: можно скомпилить код с помощью gcj и цифры поменяются.
можно с таким же успехом померить C/C++ vs Java время создания+удаления массива под 10 млн объектов. в этом тесте Java порвёт C/C++ (если не инициализировать массив данными).Т.е. микробенчмарки как по ссылке особо ничего не значат.
>> Вот странно, вроде в тестах там всяких питон особо не сливает
> Не сливает чему? Другим тормозиловам? Интерпретер не может быть быстрым по ежу
> понятным причинам.Может. Интерпретатор языка forth, к примеру, очень даже шустр.
а с чего вообще гвидобейсик (равно как и форт) в интерпретаторы записали? если они и интерпретаторы, то точно не языков python и forth, а неких VM.
С того, что и первый, и второй интерпретируют всё-таки исходники, а не какой-то там байткод. Интерпретатор питона компилирует свои проги в байткод сам и кеширует результаты, а форт и вовсе в православных реализациях никакого байткода не использует, а использует шитый код, который является родными инструкциями процессора, на котором форт выполняется.
> использует шитый код, который является родными инструкциями
> процессора, на котором форт выполняется.Остается только вопрос - нафиг нужен собственно этот форт, если можно просто скомпилить прогу на си например в нативный код и не сношать себе мозг. Ни оверхедом интерпретера, ни его наличием вообще.
> С того, что и первый, и второй интерпретируют всё-таки исходники, а не
> какой-то там байткод.гениально. покажи мне в образе форт-системы на диске исходники. и в скомпилированом питоньем модуле тоже покажи исходники.
кстати, по твоей логике gcc — интерпретатор си.
> а форт и вовсе в православных реализациях никакого
> байткода не использует, а использует шитый код, который является родными инструкциями
> процессора, на котором форт выполняется.о, вдобавок ещё и непонимание термина «шитый код» (который бывает нескольких видов).
слушай, не встревай больше в дискусии по профессиональным темам, а? охота тебе позориться?
> гениально. покажи мне в образе форт-системы на диске исходники.А почему сразу "на диске"? Можно ведь их и с клавиатуры ввести. Про "read-eval-print loop" слышали?
> и в скомпилированом питоньем модуле тоже покажи исходники.В каком "скомпилированном" питоньем модуле? Вы про файлы с расширением .pyc? Так это не модули, а всего лишь кеш. Он используется, только пока не изменён соответствующий файл .py.
> о, вдобавок ещё и непонимание термина «шитый код» (который бывает нескольких видов).
Двух. Первый вид:
start:
call fun1;
call fun2;
call fun3;
…
Второй вид:
threadcode:
fun1start:
Второй вид:
threadcode:
fun1
fun2
fun3
…
start:
mov ecx, threadcodesize;
mov esi, [threadcode];
m1:
call [esi]
add esi, 4
loop m1
Оба вида к байткоду имеют ОЧЕНЬ смутное отношение. Может, это как раз вы неправильно понимаете смысл шитого кода? По-моему, так.
> слушай, не встревай больше в дискусии по профессиональным темам, а? охота тебе позориться?Кто бы говорил.
мда, сам пишу на питоне. Но вопрос скорости исполнения приложений никогда не бывает лишним.
Все видят успехи проекта PyPy в увеличении скорости исполнения кода на Python, но при всей зрелости проекта, Гвидо даже не упоминул его. Его давно уже надо было добавлять в стабильную ветку.
http://speed.pypy.org/
ни разу не слышал в java про глобальную блокировку )
походу руки у питонистов не оттуда растут
зато, видимо, наслышан про сборщик мусора-то
в питоне нет сборщика мусора ?
и как я предполагаю он там убогий )
а jit там нет ?
и библиотек там нет уровня ИНТРЕПРАЗ ?
так зачем питон нужен ? писать скрипты из 5 строчек ?
> в питоне нет сборщика мусора ?
> и как я предполагаю он там убогий )
> а jit там нет ?
> и библиотек там нет уровня ИНТРЕПРАЗ ?
> так зачем питон нужен ? писать скрипты из 5 строчек ?у этого сборщика мусора память не течет в отличии от java
> у этого сборщика мусора память не течет в отличии от javaага, она просто в космос улетает. слова circular references о чём-то тебе говорят, нет? вот жаба с ними как-то справляется без магии и дополнительных телодвижений. и даже — о, ужас! — финализаторы умеет так, чтобы не протечь. а что там в гвидобейсике? а, вот: http://docs.python.org/reference/datamodel.html#object.__del__
не течёт, говорите? обожаю фанбоев гвидобейсика: своего же предмета обожания не знают.
html-программисты такие программисты, вас даже не жаль :)
> html-программисты такие программисты, вас даже не жаль :)тебя в детстве изнасиловал «html-программист», и теперь они тебе везде мерещатся?
> слова circular references о чём-то тебе говорят, нет? вот жаба с ними как-то справляется без магии и дополнительных телодвижений.Хрен!
package main;
import java.io.IOException;
import java.util.ArrayList;
public class Main {
static ArrayList<Object> list;
public static void main(String[] args) {
list = new ArrayList<Object>();
System.out.print("Процесс сожрал 12 Мб. Нажми Enter для продолжения. \n");
try {
System.in.read();
} catch (IOException e) {
e.printStackTrace();
}
for (short i=1; i>0; i++) {
list.add(i);
}
list.add(list);
System.out.print("Процесс сожрал еще 4 Мб и теперь занимает 16 Мб. Нажми Enter для продолжения.\n");
try {
System.in.read();
} catch (IOException e) {
e.printStackTrace();
}
list = null;
System.out.print("А теперь жди, пока жаба вернёт 4 мегабайта. Можешь нажать Enter, когда надоест ждать, потому что сама жаба тебе ничего не вернёт. \n");
try {
System.in.read();
} catch (IOException e) {
e.printStackTrace();
}
}
}
Сборщик мусора не отрабатывает каждый раз как вы какой-то переменной null присвоили. Для вас это новость? Сборщик мусора можно попросить собрать мусор(правда, соберет он его после того как вы его попросите или нет - это уж как звезды станут). Для вас это тоже новость?
Тогда почитайте о внутреннем устройстве сборщиков мусора, найдете много нового.
> Сборщик мусора не отрабатывает каждый раз как вы какой-то переменной null присвоили.Ну и что? Хотя бы один раз он отрабатывает. А если он никогда не срабатывает, зачем он вообще нужен? Ну, кроме того, чтобы снисходительно глядеть на тех, кто выделяет и освобождает память вручную?
Он срабатывает, но не сразу, а когда доступная память кончится. Afaik, по этой причине в жабе нет деструкторов, поскольку нет никакой определенности в том, когда именно объект будет уничтожен
а ты в курсе, что реализация GC совершенно не обязана «мгновенно возвращать память», нет? более того: это было бы идиотской идеей, потому что добавляет тормозов. а разговор, дорогой старшеклассник, шёл о потерях *внутри памяти, управляемой gc*. жаль, что ты этого не понял.
> реализация GC совершенно не обязана «мгновенно возвращать память»Кого вы цитируете? В комментариях выше никто о «мгновенном» возвращении памяти не говорит. GC должен возвращать память! Это всё. Вопрос в том, когда он её вернёт. Ответ — никогда. Жаль, о дорогой младшеклассник, что ты этого не понял.
> в питоне нет сборщика мусора ?
> и как я предполагаю он там убогий )
> а jit там нет ?
> и библиотек там нет уровня ИНТРЕПРАЗ ?
> так зачем питон нужен ? писать скрипты из 5 строчек ?Вот люди с таким перечнем вопросов и познаний о других языках и пишут на java.
Global Interpreter Lock кроме питона, я знаю, есть в руби. В один момент времени выполняется только один поток, что, кстати, очень актуально с ростом числа ядер и процессоров в системе (это стеб, если что).
Если у вас руки растут от туда, то попробуйте сделать без GIL так что бы в однопоточном режиме работало хотя бы не медленнее чем с GIL. Это по сути одно из главных требований Гвидо, что бы отказаться от GIL (не считая конечно сохранения совместимости). Насколько знаю, ещё никому это не удалось в полной мере.Следует отметить, что для 3-ей ветки питона были сделаны улучшения в GIL, которые существенно улучшили работу многопоточных приложений на многоядерных системах.
> Следует отметить, что для 3-ей ветки питона были сделаны улучшения в GIL,
> которые существенно улучшили работу многопоточных приложений на многоядерных системах.мне вот непонятно, почему расширения stackless не втянут в стандартный cpython. как и гринлеты. сделали бы как в erlang: пул потоков уровня приложения маппится в пул потоков операционной системы.
гринлеты это убогие костыли, их никуда впихивать не нужно. Стаклесс, как и в случае без GIL, заметно медленнее традиционного CPython.
> гринлеты это убогие костыли, их никуда впихивать не нужно. Стаклесс, как
> и в случае без GIL, заметно медленнее традиционного CPython.эти костыли работают. или вы предлагаете писать длинные портянки коллбэков и молится, чтобы где-то синхронный вызов не поставил всё раком?
ну и вообще, какие альтернативы в случае i/o bound задач и большого количества соединений?
читайте документацию, ее для вас писали
> читайте документацию, ее для вас писалиа по делу сказать есть что?
в питоне есть поддержка многопоточности сравнимая с java ?
да же если и есть, думаю это бажная вещь потому как написать такую подсистему недостаточно любить питон нужно ещё уметь программировать.
> в питоне есть поддержка многопоточности сравнимая с java ?
> да же если и есть, думаю это бажная вещь потому как написать
> такую подсистему недостаточно любить питон нужно ещё уметь программировать.скажите, а зачем нужна многопоточность?
"A Computer is a state machine. Threads are for people who can't program state machines" (c) Alan Cox
> скажите, а зачем нужна многопоточность?
> "A Computer is a state machine. Threads are for people who can't
> program state machines" (c) Alan CoxЗатем что нынче технологии позволили засовывать на 1 кристалл более чем 1 state machine. Поэтому использовать машины состояний надо тоже с умом. Хотя-бы запустив их по числу ядер, бэть.
>> скажите, а зачем нужна многопоточность?
>> "A Computer is a state machine. Threads are for people who can't
>> program state machines" (c) Alan Cox
> Затем что нынче технологии позволили засовывать на 1 кристалл более чем 1
> state machine. Поэтому использовать машины состояний надо тоже с умом. Хотя-бы
> запустив их по числу ядер, бэть.ну запустить процессов по числу ядер, не?
nginx обходится без нитей же.
> Если у вас руки растут от туда, то попробуйте сделать без GIL
> так что бы в однопоточном режиме работало хотя бы не медленнее
> чем с GIL.если я правильно помню, что это, то могу сказать, что у автора Nasal вполне получилось. наверное, потому, что автор Nasal — хороший программист, а автор гвидобейсика — не очень.
> от туда,^^^^^^^ FAIL :P. Almost epic.
Есть только один случай, когда Java-кодеры используют GL. Это использование вызовов в безопасном режиме(когда надо гарантированно сохранить целостность объектов). Блокировка ставится и снимается VM настолько быстро, что в этого и не заметите. Так было при использовании VMThread из состава HotSpot. Вроде Оракул что-то делал, что-бы изменить ситуацию.
Ван Россум: Пайтон вовсе не так медлителен
Пол Крилл
16 марта 2012 г.
Гвидо ван Россум — создатель пайтона [1], одного из множества имеющихся сегодня динамических языков, который применяется в таких организациях, как «Гугл» и НАСА. В прошлое воскресенье ван Россум (штатный инженер-программист «Гугл») после своего выступления на конференции «ПайКон» («PyCon») в Кремниевой Долине встретился с общественным редактором «Инфоуорлд» Полом Криллом и рассказал о пайтоне, ответив его критикам.
(См. тж. недавнее интервью с изобретателем си++ Бьорном Страуструпом [2], касающееся последних новинок этого языка).
«Инфоуорлд»: Вы возражали критикам, утверждавшим, что пайтон слишком медлителен, заявляя, что все, что пытались написать на пайтоне [3], получалось достаточно быстрым. Откуда же критика, касающаяся его чрезмерной медлительности?
Ван Россум: Ну так ведь люди берут инструмент и пишут что-то невероятное, и делают нечто безумное в ходе написания этих невероятных штуковин. Иногда такое безумие связано с кучей вычислений, обходом графа с миллиардом социальных связей или анализом триллиона сообщений электронной почты или чем-то таким.
Рано или поздно дело кончается тем, что одним небольшим куском всей создаваемой системы поглощаются все ресурсы. Если вы простодушно оформите его как простой пайтоновский цикл, вы увидите в конце концов, что он и станет узким местом вашей системы. Обычно гораздо быстрее взять этот кусок и переписать его в виде функции или модуля на си или си++, чем переписывать всю систему на более быстром языке, поскольку для большей части того, что вы делаете, скорость языка не имеет значения.
«ИУ»: Какая версия языка является текущей?
ВР: Прямо сейчас существует две разные версии. Есть две ветви языка, которые мы стараемся в конце концов объединить. Мы пытаемся покончить с ветвью пайтон-2, так что последним листом на этой ветке будет пайтон-2.7. Но пайтон-2.5 и 2.6 все еще широко применяются. В рамках ветви пайтона-3 текущим релизом является 3.2, а недавно мы выпустили альфа-версию 3.3, так что через несколько месяцев она станет текущей.
«ИУ»: Что наиболее привлекательно в третьей ветви пайтона?
ВР: В пайтоне-2 накопилось множество разных способов делать одно и то же. Кроме того, пайтон-2 обеспечил возможность работы с юникодом. Когда мы ввели ее в 2001 г., мы очень гордились наличием поддержки юникода и обратной совместимостью. Где-то к 2006–7 г. мы сообразили, что к юникоду нужен совсем другой подход, и мы не можем обеспечить совместимость этого правильного подхода со старой версией нашего языка.
Это было одним из соображений, заставивших нас вместо минорных релизов, жестко ограниченных необходимостью обратной совместимости, выпустить новый релиз: пайтон-3. Мы собираемся подчистить кучу вещей и исключить возможности, которые уже объявлены устаревшими. Программисты будут знать, что пайтон-3 несовместим с пайтоном-2, но ощущаться он будет как почти тот же самый язык.
«ИУ»: Если они несовместимы, то прикладные программы на пайтоне-2 придется перекомпилировать?
ВР: В большинстве случаев исходный код на пайтоне-2 придется переписать. Мы предоставляем инструментальную программу под названием «2to3», которая большинство изменений вносит в код автоматически. Но не все подвластно автоматизации, так что код придется проверить вручную. А некоторые уже приняли стратегию писать на ограниченном подмножестве пайтона-2, не используя некоторых возможностей, так что их исходный код уже волшебным образом совместим с пайтоном-3.
«ИУ»: Вы говорили о доводах как в пользу динамической типизации, так и против нее. Вы сказали, что если бы верили в способность компилятора найти все ошибки в программе, долго программистом не проработали бы. Вы, таким образом, удовлетворены динамичностью типизации в пайтоне?
ВР: Совершенно верно. Основная философия языка не будет меняться. Я не представляю, что у пайтона вдруг появится подмножество типов со статической типизацией. Я не ожидаю даже небольших шагов в этом направлении.
«ИУ»: В докладе вы упомянули, что считаете реалистичной возможность глобального статического анализа типизации в программе на пайтоне. Что это дало бы пишущим на нем разработчикам?
ВР: Посредством статического анализа типизации можно находить ошибки определенного рода. Кроме того, можно заняться оптимизацией.
«ИУ»: Является ли глобальная блокировка интерпретатора (GIL) препятствием для многоядерного программирования, или дело обстоит по-другому?
ВР: Дело обстоит примерно так, как вы сказали. Если у вас несколько ядер, вы не можете заставить каждое ядро исполнять пайтоновский байткод, поскольку пайтоновский байткод нуждается в глобальной блокировке, а она доступна только для одного ядра. Нити исполнения на пайтоне без GIL способны лишь ждать ввода-вывода или же запускать код, написанный на си или си++.
Например в расширении «NumPy», предназначенном для манипулирования большими матрицами, при передаче ему матрицы или большого массива с указанием вычислить функцию над 10 млн ее элементов, она отдает блокировку ядру интерпретатора. Я не знаю, есть ли в «NumPy» аппаратное распараллеливание, но представьте, что у вас есть хоть 10 ядер, и вы можете разделить счет на 10 ядер, и они способны параллельно обрабатывать разные данные, и ни одному из них не нужна глобальная блокировка: ведь они не манипулируют пайтоновскими объектами.
Эта статья («Ван Россум: Пайтон вовсе не так медлителен» [4]) впервые обнародована по-английски на сайте «InfoWorld.com»
URL: http://www.infoworld.com/d/application-development/van-rossu...
Ссылки:
[1] http://www.infoworld.com/d/application-development/pillars-p...
[2] http://www.infoworld.com/d/application-development/stroustru...
[3] http://www.infoworld.com/d/application-development/pillars-p...
[4] http://www.infoworld.com/d/application-development/van-rossu...
В соседней ветке http://www.opennet.me/opennews/art.shtml?num=33381 описан проект SkyTools 3.0 http://wiki.postgresql.org/wiki/SkyTools .
Skytools используется для обеспечения работы крупнейшего в мире PostgreSQL-кластера, обслуживающего базу абонентов Skype (более миллиарда пользователей). Код проекта в большей части написан на языке Python (имеются компоненты на Си) и распространяется в рамках лицензии BSD.
Такие проекты на медленных языках не делаются.
> Такие проекты на медленных языках не делаются.именно поэтому все важные по скорости части и не сделаны там на гвидобейсике. а обёртки хоть на баше можно фигачить, это почти без разницы.
> а обёртки хоть на баше можно фигачить, это почти без разницы.У баша есть лютый плюс: не надо таскать по 3-4 версии оного для совместимости с собой любимым в молодости. А у автора гвидобэйсика зуд пониже спины, чем он реально задрал уже.
>> а обёртки хоть на баше можно фигачить, это почти без разницы.
> У баша есть лютый плюс: не надо таскать по 3-4 версии оного
> для совместимости с собой любимым в молодости. А у автора гвидобэйсика
> зуд пониже спины, чем он реально задрал уже.Ну не пользуйся ты "гвидобэйсиком", не пользуйся... Кончай ныть и сделай свой "петябэйсик" сам знаешь с чем!
Что-то интервью ни о чем. А питон мне нравится. Использую повсеместно как вспомогательный инструмент. Простой и выразительный синтаксис, куча библиотек, кросплатформенный - писать скрипты до 1000 строк вообще не напрягает.
Вообще Питон - классный язык! Все пишу на нем. Всем доволен.
А главное, всегда легко читается, и не надо писать скобок, да и вообще лишних символов.
cool-язык в общем)))
Поглядел вики про ГР, тама написано что он в гугле пилил - code-review.
Кто даст ссылку где это скачать и почитать про это. Все что нахожу не много нето :(
"лишних символов" - это вы про пробелы да табуляции?
Символов может и больше получается, зато код читать/разбирать легче.
> Символов может и больше получается, зато код читать/разбирать легче.ну да, ЦА гвидобейсика такая, что если их насильно не заставлять отступы в коде делать, то они будут писать нечитаемые портянки.
> cool-язык в общем)))Для кул-скрипткиддей. И ник подходящий, и стиль. Ну короче не зря ему название гвидобэйсик придумали, раньше такие как раз бэйсик пользовали :)
> ...из-за неумения подобрать должный инструмент для решаемой задачи и провести надлежащую оптимизацию...Ну да. Миллионы мух - дураки, одна пчела - молодец! :)
"переписывать на Си" критичные участки - это и есть сознаться "мой язык - полное Г и служит только для прикольных перделок!".
Почему-то ни один сишарповый проект, да не подскочит ваше давление, не использует подобных хаков (пришедших из 80-ых). Просто потому, что за сам язык разработчик спокоен и не тратит время, проверяя "кто виноват" - виноват всегда прогер. И он берёт и профилирует подозрительные участки.
Кстати, недавно оптимизировал запрос структуры БД - с минуты до 2-3 секунд. Сегодняшний способ получить эту структуру - полное Г, пришлось писать кучу джойнов.
Если вы не знали, то шарпы вполне себе позволяют использовать вызовы нативных библиотек, а так-же (о ужас!) unmanaged code. Исходя из вашей логики - он тоже "служит только для прикольных перделок" и от гвидобейсика не отличается.
Какое отношение ваши неясные потуги с БД имеют к гвидобейсику совсем не понятно.
>Ну да. Миллионы мух - дураки, одна пчела - молодец! :)Как я понял ты хочешь сказать, что ты Д'Артаньян...
>"переписывать на Си" критичные участки - это и есть сознаться "мой язык - полное Г и служит только для прикольных перделок!".
Так как куча людей переписывают критические участки используя подходящие средства. А ты просто записал все языки программирования в категорию "полное Г", т.к. даже с Си переписывают на ASM.
>Почему-то ни один сишарповый проект, да не подскочит ваше давление, не использует подобных хаков (пришедших из 80-ых).
Ты видел все C# проекты? Множество проектов если не используют явно код на Си, С++ и т.д., то делают это неявным образом, через сторонние библиотеки, в том числе и из-за скорости: кодеки, числодробилки.
Так же имеет место и обратное - использование тормозных, но более удобных ЯП совместно с С, Java и т. д.
По-моему это и есть: "умение подобрать должный инструмент для решаемой задачи и провести надлежащую оптимизацию..."
> По-моему это и есть: "умение подобрать должный инструмент для решаемой задачи и
> провести надлежащую оптимизацию..."Это точно про сишарперов и питонистов? А у меня такое ощущение что типовой сишарпер или питонист на это клинически не способен :)
>> По-моему это и есть: "умение подобрать должный инструмент для решаемой задачи и
>> провести надлежащую оптимизацию..."
> Это точно про сишарперов и питонистов? А у меня такое ощущение что
> типовой сишарпер или питонист на это клинически не способен :)Как в принципе и типовой кодер на Java, JavaScript и т.д.
А у меня такое ощущение, что вы ни в С# ни в Python-е не разбираетесь. И, пожалуйста, определение "типовых сишарперов и питонистов" в студию.