Обзор новых возможностей в Python 2.6 и 3.0

2anonymous (*) (29.06.2008 14:04:57):

>> Кто там про производительность выше говорил? Груви жутчайший
>> тормоз. Плюс к тому в плане синтаксиса ужасен. До Python ему далеко.

> Кто там говорил, что скорость не главное?

Правильно, я так говорил. Но писать, что Питон тормоз, и тут же
приводить в пример Груви - это смешно. В чём соль-то такого аргумента?

> P.S. Просвети меня, что ужасного в синтаксисе груви?

Ничего ужасного. Всё тот же C-подобный синтаксис. То есть, в плане
улучшения читаемости ничего нового.

звиздеч, java уже стала скриптовым языком

>А для Вас это открытие что ли? Ну сравните аналогичное на Python, Java, C++ и поймете, что такое высокоуровневый язык. Там, где в Python одна строчка, в Java десяток. Хотя согласен, Java1.5 уже как-то попыталась исправить это. Шажок вперёд есть. Меньше мути стало хотя бы с итераторами.

Господи, вот ламерья то понабежало.... Довожу до вашего сведения что "уровень" языка опредляется абстракциями (классы, функции высших порядков, правила, запросы и пр.), которыми он оперирует, а не синтаксическим сахаром.

Маленький провокационный вопрос: как вы считаете ABAP является выскоуровенвым языком? И что является более выскоуровневым - ABAP или питон? А что если рассмотреть пару - питон <-> 1с? Что является более высокоуровневым - язык общего назнчения или DSL?

2tailgunner ** (*) (29.06.2008 13:59:17):

>> PyPy очень перспективен в этом и других планах.

> Да он уже столько времени "преспективен" :(

Google начинает помогать двигать это дело ;-)

http://morepypy.blogspot.com/2008/06/pypy-improvements.html

>> Непонятно предназначение with. Ну, то есть, какие новые >> возможности появляются в сравнении с try/finally ? > Это совсем другое. Почитайте доки.

Мгхм... Typical uses of context managers include saving and restoring various kinds of global state, locking and unlocking resources, closing opened files, etc. Ну, то есть, документация (на docs.python.org/ref/ ) позиционирует контекст-менеджеры, как более формализованную замену тому же try/finally, с помощью которого подобные задачи и решаются в "старом" питоне или яве.

> PEP 3107

О, дак в аннотациях не только замена epydoc'оковскому документированию, но и формальные проверки, встроенные "в язык" или "стандартную библиотеку" будут?

Потому как организовать проверку на уровне кастомных декораторов или метаклассов возможно уже сейчас (спасибо tailgunner за наводку про ize!), но пока получается, кто в лес, кто по дрова, одних только epydoc-like документаторов, по-моему, не меньше двух альтернативных...

> PyPy очень перспективен в этом и других планах.

Э-хе-хе... Как гласит поговорка американских империалистов, Мексика - это очень перспективная страна. И навсегда останется таковой. Или я чрезмерно пессимистичен и/или пропустил какие-то важные майлстоуны в жизни pypy?

Бля. люблю когда програмеры друг друга ебуть.

PS . пошел за пивом на кухню. Чую будет знатная потасовка.

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

> Нет не тебе одному. +) имно кошмарные конструкции.

Зато нет нужды изобретении нового синтаксиса каждый раз, когда всплывает очередная мегаидея в программировании :-)

Желающим посравнивать "простоту языка" рекомендую обратить внимание на размер и сложность формального (EBNF, например) описания тех или иных языков, количества зарезервированных слов в них и т.п.

2anonymous (*) (29.06.2008 14:12:22):

> Господи, вот ламерья то понабежало.... Довожу до вашего сведения что
> "уровень" языка опредляется абстракциями (классы, функции высших
> порядков, правила, запросы и пр.), которыми он оперирует, а не
> синтаксическим сахаром.

Круто ты тут навернул. А теперь и покажи на основе своего определения,
чем Java более высокоуровневая, чем Python. Потому что для нормальных
людей high level означает easier to use, easier to write/read/maintain.
Дальше от машинного языка и ближе к человеческому восприятию.

А потом сравни аналогичные конструкции на Python и Java и воспринимай
то и это.

> Маленький провокационный вопрос: как вы считаете ABAP является
> выскоуровенвым языком?

Не знаком с ним. Так что провокация не удалась.

> Google начинает помогать двигать это дело ;-)

> http://morepypy.blogspot.com/2008/06/pypy-improvements.html

Я регулярно читаю этот блог и архив девелоперского листа :) Но вот эта фраза: "With more efforts like this one we're hoping that PyPy can start to be used as a CPython replacement before the end of 2008" значит, что до конца 2008г (а может, и позже) точно не будет работоспособного интерпретатора. И даже когда он появится, непонятно, будет ли он быстрее CPython. В общем, PyPy - дело еще более далекого будущего, чем Питон3К, ИМХО.

>Дальше от машинного языка и ближе к человеческому восприятию.

Правильно, поэтому смотри в сторону 1с и ABAP. К слову функциональное программирование довольно далеко от "нормального" человеческого восприятия

2anonymous (*) (29.06.2008 14:17:42):

> Бля. люблю когда програмеры друг друга ебуть.
> PS . пошел за пивом на кухню. Чую будет знатная потасовка.

Да какая потасовка. Все прекрасно знают, что Python крутой язык,
но потявкать-то охото. Сидит там где-то красноглазый в подвале
своём, пишет на ЦэПлюсПлюс, а самого зависть душит, что там наверху
люди пишут на Python. И пока этот стряпает конструкторы копирования
и затыкает утечки в коде, Python'щик пьёт пиво и с девками гуляет.

2anonymous (*) (29.06.2008 14:27:01):

>> Дальше от машинного языка и ближе к человеческому восприятию.

> Правильно, поэтому смотри в сторону 1с и ABAP.

Да, более высокоуровневые, но и намного более узкоспециализированные.
Python - лучший компромисс для большинства задач.

> К слову функциональное программирование довольно далеко от
> "нормального" человеческого восприятия

К слову сказать, я никогда и не был сторонником чисто функциональных
языков. И всегда считал, что это непрагматично и бесчеловечно :)

>Да какая потасовка. Все прекрасно знают, что Python крутой язык, но потявкать-то охото. Сидит там где-то красноглазый в подвале своём, пишет на ЦэПлюсПлюс, а самого зависть душит, что там наверху люди пишут на Python. И пока этот стряпает конструкторы копирования и затыкает утечки в коде, Python'щик пьёт пиво и с девками гуляет.

Правильно, потому что больше ни на что у питонщика денег не хватает, а в центральном офисе сидит абапер, который только что купил себе новую квартиру в центре. Хе-хе

P.S. Господа, зарубите на своем красноглазом носу - хорош тот инструмент, который решает больше проблем, чем создает их.

Очень серьёзная уязвимость. Ждём патчей!

> К слову функциональное программирование довольно далеко от "нормального" человеческого восприятия

Императивное - тоже.

> а в центральном офисе сидит абапер, который только что купил себе новую квартиру в центре.

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

> P.S. Господа, зарубите на своем красноглазом носу - хорош тот инструмент, который решает больше проблем, чем создает их.

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

>Да, более высокоуровневые, но и намного более узкоспециализированные.

Хорошо, вменяемый любитель питона это уже чудо! А теперь сравни питон с немерле/F# и скалой с практической точки зрения (учтя при этом, что за ними стоят .NET/J2SE/EE и соответствующие крупные игроки). И наложи это сравнение на ситуацию с PyPy и прочими свистоперделками для питона.

P.S. Я думаю, объяснять дальше тебе ничего уже не придется - питон имеет будущее, но только как Jython или IronPython - как один из языков для одной из глобальных платформ и вот тут ему придется напрямую конкурировать с groovy/boo и scala/nemerle. Как думаешь сколько леммингов предпочтут питон?

> питон имеет будущее, но только как Jython или IronPython - как один из языков для одной из глобальных платформ

Пока есть программы, которые работают не на "одной из глобальных платформ", у Питона есть будущее и вне их.

> ему придется напрямую конкурировать с groovy/boo и scala/nemerle

Scala еще не встала на крыло. А Nemerle разве кто-нибудь использует? Судя по девелоперскому листу и блогу, он уже год как мертв.

> Я думаю, объяснять дальше тебе ничего уже не придется - питон имеет будущее, но только как Jython или IronPython - как один из языков для одной из глобальных платформ и вот тут ему придется напрямую конкурировать с groovy/boo и scala/nemerle. Как думаешь сколько леммингов предпочтут питон?

Пророк? Извините, не признали, так что хотелось бы доказательств. Например, Питон уже убрали из LSB? Питон под глобальную платформу будущего, на мой взгляд, скорее *не* имеет, история с Jython это подтверждает, IronPython с платформой интегрирован одностороне, а самоплатформенный Python вполне живой.

И как только программирование связано с сильным использованием CLR/JVM библиотек, код на *питоне становится примерно таким же ужасным, как год на Java 1.2 и C# 1.0 :(

> вот тут ему придется напрямую конкурировать с groovy/boo и scala/nemerle. Как думаешь сколько леммингов предпочтут питон?

1. Лемминги и манагеры не в курсе и про boo/nemerle/scala/grrovy. 2. Who cares? К тому моменту весь init.d на нем перепишут ;)

> Scala еще не встала на крыло.

Ничё, jetbrains-ы обещали хорошую поддержку скалы в идее, как реализуют, так скала всех сразу и зарулит.

2anonymous (*) (29.06.2008 14:42:33):

>> Да, более высокоуровневые, но и намного более узкоспециализированные.

> Хорошо, вменяемый любитель питона это уже чудо!

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

> А теперь сравни питон с немерле/F# и скалой с практической точки
> зрения

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

F#, как язык, мне нравится. Вернее, я писал и иногда ещё пишу
на OCaml, но это близко. Но сравнивать с Python, извини, не стал бы.
Совершенно разные языки.

Scala мне не понравилась совсем. Хотя это не значит, что за ним
нет будущего.

> (учтя при этом, что за ними стоят .NET/J2SE/EE и соответствующие
> крупные игроки).

Про технологии -- вопрос отдельный. Не мешай мух с котлетами.

2anonymous (*) (29.06.2008 14:54:27):

>> Scala еще не встала на крыло.

> Ничё, jetbrains-ы обещали хорошую поддержку скалы в идее, как
> реализуют, так скала всех сразу и зарулит.

Ещё раз -- ВСЕХ не зарулит. Scala зарулит Java, но не всех.
И зарулит ли, ещё спорный вопрос. К чему гадать, если язык ещё не
вылез толком из академической среды.

Зарулит конечно, фаулер с бучем объявят, что нынче модно ФП и индусы потянутся.

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

это да, бывает

>не имея понятия ни о чем, кроме парочки ключевых слов в любимом Питоне

а вот это - 4.2

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

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

>Я знаю гораздо больше, чем 98% здешней аудитории

видимо, ты хорошо это скрываешь

>А прочитал я достаточно много книжек, даже по вещам, которые мне противны

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

>Приятной беседы

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

2anonymous (*) (29.06.2008 14:33:17):

> Правильно, потому что больше ни на что у питонщика денег не хватает,

Какие деньги? Когда про девок писал, я не валютных проституток имел
ввиду.

> а в центральном офисе сидит абапер, который только что купил себе
> новую квартиру в центре. Хе-хе

В центре чего? Москвы? Спасибо, не надо. Верблюжатину не едим.
Давитесь сами своим 'свежим' московским воздухом.

> P.S. Господа, зарубите на своем красноглазом носу - хорош тот
> инструмент, который решает больше проблем, чем создает их.

AK-47 ?

> у специалиста не может быть вещей, которые ему противны

Может-может. Специалист всё-таки человек, а не робот.

> 10 раз медленнее Явы - это адекватная? Вы бы сначала хоть ознакомились в вопросом как-то.
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all

Ой, мне так нравятся эти тесты... ;-)
По которым венда - рулез, все выбирают windows server system, которая рвет на куски Free BSD на иНет-серверах...

>Может-может. Специалист всё-таки человек, а не робот

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

> Ой, надо же! А когда те же аргументы приводят в пользу жабы - сбегается весь ЛОР и дружно начинает хаять яву и при этом ссылаются как раз на числодробилки - это уже называется двойные стандарты.

Объясняю.

Создатели Python/Perl/PHP (далее 3P) всегда были трезвы умом и понимали, что им не обогнать Си. Потому для них существует удобный API для Си. Потому существует бесчисленное множество сишных библиотек и биндингов. В любой книжке про 3P пишут - делайте как можно больше вызовов встроенных функций, реализованных на Си, как можно меньше отсебятины. Примерно такой код на 3Р и пишется.

Совсем иная ситуация с Java. Разработчики тронулись умом, однозначно. Провозгласили свой недоязычок пупом земли, понапридумывали кучу тестов, где Java обгоняет Си, и ГЛАВОЕ отказались от Си в качестве языка встроенных библиотек. Все, абсолютно все, они предлагают и делают на Java.

Потому и получается, что в реальности 3Р работает на скорости Си, а Java на скорости Java. Потому и сравнивают Java и Си. И Java проигрывает, как бы не извращалась. Природу не обманешь, быстрее процессора работать не заставишь.

Хотите реального сравнения? Возьмите то же цикл и вставьте в тело, к примеру, разбор регулярками. Реализация регулярных выражений на Java проиграет в десять раз, минимум.

Программист на 3P прекрасно понимает, что Си не обогнать. И в сложных ситуациях берется за Си. А не за ключи запуска Java-машины.

какое убожество эти "{0:d}{1:X}"!!

Чем плох стандартный формат printf?

Весьма интересная мысль. Только всё на Java стараются писать не от хорошей жизни. Да и на С писать в случае Java очень просто, JNI хорошо сделан и документирован.

> Хотите реального сравнения? Возьмите то же цикл и вставьте в тело, к примеру, разбор регулярками. Реализация регулярных выражений на Java проиграет в десять раз, минимум.

Давайте сравним. С, пайтон и джаву. Предоставлю код на джаве. Только условие - время работы на С не менее 20 секунд. На пайтоне и джаве использовать только стандартные библиотеки.

полностью согласен, от первого до последнего слова. единственно что вместо 3P можно было сказать просто "скриптовых языков" - и Tcl и, скажем, REBOL, под описание подходят аналогичным образом

>> Возьмите то же цикл и вставьте в тело, к примеру, разбор регулярками. Реализация регулярных выражений на Java проиграет в десять раз, минимум.

> Давайте сравним. С, пайтон и джаву.

Это типа grep -r на, скажем, тексты ядра?

Нормальные регулярные выражения будут работать со скоростью считывания файла. Я имел в виду синтетические тесты вроде 100000 компиляции и 10 раз выполнения регулярного выражения.

/me

> Нормальные регулярные выражения будут работать со скоростью считывания файла.

На "теплом" кэше? Нет. Другое дело - разве в Яве разбором регэкспов занимается Ява-код? Я думал, что родной.

> Я имел в виду синтетические тесты вроде 100000 компиляции и 10 раз выполнения регулярного выражения.

После 100000 компиляций - зачем его выполнять? :) Время на не-гигантской строке будет пренебрежимо малым.

> После 100000 компиляций - зачем его выполнять? :) Время на не-гигантской строке будет пренебрежимо малым.

Я имел в виду выполнять 10 раз после каждой компиляции. В принципе это не существенно.

> разве в Яве разбором регэкспов занимается Ява-код?

Да. В сановской JDK 1.5 по крайней мере, в других не смотрел.

> Я имел в виду выполнять 10 раз после каждой компиляции.

Псевдокод в студию. Для случая одного файла.

Сорри, вот корректная версия.

import java.util.regex.Pattern;

public class Main {
	public static void main(String[] args) {
		long start = System.currentTimeMillis();
		String arr[] = new String[10];
		for (int i = 0; i < arr.length; ++i) {
			StringBuilder sb = new StringBuilder();
			for (int j = 0; j < i * 100; ++j) {
				sb.append(Character.forDigit(j % 10, 10));
			}
			arr[i] = sb.toString();
		}
		
		Pattern pattern;
		
		for (int k = 0; k < 10000; ++k) {
			pattern = Pattern.compile("(" + String.valueOf(k) + ".+)+");
			for (int j = 0; j < arr.length; ++j) {
				pattern.matcher(arr[j]).find();
			}
		}
		System.out.println((System.currentTimeMillis() - start) + " ms");
	}
}

> Давайте сравним. С, пайтон и джаву. Предоставлю код на джаве.
> Только условие - время работы на С не менее 20 секунд. 

Начнем с Си:

#include <stdio.h>
#include <regex.h>
#include <string.h>

int main(){
	char subject[] = "Re[42]: some subject this";

	int num;
	char num_str[5]="";
	regex_t re;
	regmatch_t rm[2];


	int i,l=0;
	for(i = 0; i < 1000000; i++)
	{
		if( regcomp(&re, "^Re\\[([0-9]{0,5})\\]:", REG_EXTENDED|REG_ICASE) )
		{
			printf("ERROR\n");
			return 1;
		}

		if( !regexec(&re, subject, 2, rm, 0) )
		{
			strncpy(num_str, &subject[rm[1].rm_so], rm[1].rm_eo - rm[1].rm_so);
			num = atoi(num_str);
			l += num;
		}
		regfree(&re);
	}

	printf("\nTotal:%d\n", l);
	return 0;
}


Критика? Посложнее строку и регурярку кто-нибудь может придумать?
Компиляция нарочно внутри цикла.

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

какой всё же ужоснах эта Ява :/

import re, time

t1 = time.time()
arr = []
for i in xrange(0, 10):
        s = ""
        for j in xrange(0, i*100):
                s += str(j % 10)
        arr.append(s)

t2 = time.time()
for k in range(0, 1000):
        pattern = re.compile("(" + str(k) + ".+)+")
        for s in arr:
                pattern.match(s)

t3 = time.time()
print t3 - t1, t2 - t1, t3 - t2

Что то PHP нынче обнаглел, вперед Си пошел:

gcc time.c -O3
time ./a.out 

Total:42000000

real	1m30.692s

Теперь надежный и глобальный. А главное быстрый ;)

<?php
$subject = "Re[42]: some subject this";
$l = 0;
for($i=0; $i < 1000000; $i++) {
	preg_match("/^Re\[([0-9]{0,5})\]:/", $subject, $rm);
	$l = $l + $rm[1];
}

echo "\nTotal:$l\n";


time php regex.php 

Total:42000000

real	0m6.378s


Почему? POSIX и PRCE, и видимо PHP сохраняет откомпилированный
шаблон. Потому нужен Python, он себе таких вольностей не
позволяет.

Си без перекопиляции - компиляция за циклом:

time ./a.out 

Total:42000000

real	0m8.277s


Ай да ПЫХПЫХ, а да молодец!


#include <stdio.h>
#include <regex.h>
#include <string.h>

int main(){
	char subject[] = "Re[42]: some subject this";

	int num;
	char num_str[5]="";
	regex_t re;
	regmatch_t rm[2];

	if( regcomp(&re, "^Re\\[([0-9]{0,5})\\]:", REG_EXTENDED|REG_ICASE) )
	{
		printf("ERROR\n");
		return 1;
	}

	int i,l=0;
	for(i = 0; i < 1000000; i++)
	{


		if( !regexec(&re, subject, 2, rm, 0) )
		{
			strncpy(num_str, &subject[rm[1].rm_so], rm[1].rm_eo - rm[1].rm_so);
			num = atoi(num_str);
			l += num;
		}
	}

	regfree(&re);

	printf("\nTotal:%d\n", l);
	return 0;
}

Вариант с С у меня при 100000 работает 17.6 секунд.

import java.util.regex.Matcher;
import java.util.regex.Pattern;

class test {
    public static void main(String[] args) {
        String subject = "Re[42]: some subject this";
        String patternStr = "^Re\\[([0-9]{0,5})\\]:";
        int l = 0;

        long timeStart = System.currentTimeMillis();
        
        for (int i = 0; i < 100000; ++i) {
            Pattern pattern = Pattern.compile(patternStr);
            Matcher matcher = pattern.matcher(subject);
            matcher.find();
            l += Integer.parseInt(matcher.group(1));
        }
        
        System.out.println("Total: " + l);
        System.out.println("Total time: " + (System.currentTimeMillis() - timeStart) + " ms");
    }
}

Это работает 828 миллисекунд. Ну что, джава опять обогнала С в 20 раз гыгы :)

Вообще дурацкая идея, там разные реализации этих регвыров и мы сраниваем несравнимые вещи.

> Ну что, джава опять обогнала С в 20 раз гыгы :)

Кэширование, вероятно. Сравни еще Питон-вариант с Явой.

А вообще, надо сделать grep -r на теплом кэше.

Пока всё, ччто удалось выяснить, - это что реализация регулярных выражения из glibc сосёт.

> Вариант с С у меня при 100000 работает 17.6 секунд.

У тебя неправильный C. У меня миллион за 8 секунд отрабатывает.

Вряд ли рекомплилирует. Вынеси компиляцию за цикл. И сравни вермя. Если не измениться - ложь.