Python 3000

Апупеть. А чем плох теперешний питон?

А в предисловии к книге Марка Лутца, он говорил о постепенном переходе. :) Правдо то было 5 лет назад. :) Видать изменил взгляды.

R.I.P :(

питон2 и питон3 будут существовать параллельно

а этой новости сто лет в обед

> Гвидо ван Россум официально запустил процесс по созданию новой версии Python, отличительной чертой которого является его обратная несовместимость с предыдущими версиями

Гмм... А чем это будет отличаться от нынешней ситуации ?

питон все пытается догнать перл (у которого 5 и 6 не совместимы :) )

интересно, а паррот у него появится?

А python когда-нибудь будет нормально компилироваться (или прекомпилироваться) в исполняемый, неинтерпретируемый код? (ну, кроме psyco если)

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

А тем, что с выходом новой версии 2.x.x нынешний код у тебя продолжает работать. В Python 3000 будут такие изменения, которые сломают фундаментальные вещи. Например, деление.

Так же планируется избавиться от функций map(), filter(), reduce(). Избавиться от `lambda`. Гвидо даже не нравиться выражение `print`. Его планируется заменить на функцию `write`.

Все подробности вакханалии тут: http://wiki.python.org/moin/Python3.0

Ну, почему же. Типа увеличение производительности и всё такое. Допустим, если использовать python для расчётов (о ужас :-)

> питон все пытается догнать перл (у которого 5 и 6 не совместимы :) )

> интересно, а паррот у него появится?

Ну, ээ. Python 2 на парроте более-менее работает, если я не ошибаюсь (ну минус интерфейс с native code). Ни вижу, что может помешать Гвидо сделать попугая или моно или JVM или Nico "официальным" таргетом питона-3. Особенно если паррот правда появится в дистрибутивах (после выхода альфы Perl6), и учтя, что моно уже почти везде есть и правда работает (Beagle - это модно, и все такое).

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

хорошая цель, не сомневаюсь, что она будет достигнута :)

афигеть дайте две :)

"А тем, что с выходом новой версии 2.x.x нынешний код у тебя продолжает работать."

Да ну ?

Разработчики GTK, QT и Xorg могут постараться и к пасхе поломать совместимость с предыдущими версиями!

Вот после этого венде точно писец!

Remove the lambda statement. [1] [4]

Instead: use a local function.

Reason: lambda supports only one expression.

Remove apply(). [1]

Instead: use f(*args, **kw).

Remove xrange(). [1] [4]

Instead: use range().

Remove map() and filter(). [1] [4]

Instead: use list comprehensions.

Remove reduce(). [1]

Instead: use a loop.

Зашибись. Это чё, ликвидируют всю функциональщину? array.map(lambda ...) уже не прокатит?

Бородку сбрейте! :D

Питон 3000 придумали _очень_ давно. И PEP 3000 завели ещё фиг знает когда. Как минимум, больше года назад, это точно.

> Это чё, ликвидируют всю функциональщину?

Сказано же, use list comprehensions. :) Хотя для особых фанатов, наверно, оставят и map, и filter, просто засунут в отдельный модуль.

Это новый PEP 3000 (Created: 05-Apr-2006 by GvR)

Старый переименовали в PEP 3100 (Created: 20-Aug-2004 by amk)

http://www.python.org/dev/peps/pep-3100/

здесь рассказывается о том, что планируется сделать. это не утверждённый и окончательный план, а скорее наброски -- "The list of features included in this document is subject to change and isn't binding on the Python development community; features may be added, removed, and modified at any time."

вкратце -- подчистить язык ("A general goal is to reduce feature duplication by removing old ways of doing things. A general principle of the design will be that one obvious way of doing something is enough") и стандартную библиотеку ("Reorganize the standard library to not be as shallow").

некоторые изменения (безусловно, нужные) ломают обратную совместимость, однако портирование старого кода под 3000, скорее всего, не будет представлять особой сложности -- никаких принципиальных/фундаментальных изменений не будет.

> Remove the lambda statement. [1] [4]

http://mail.python.org/pipermail/python-dev/2006-February/060415.html "Let's just *keep* lambda" -- GvR

ждем ебилдов.
Как дождемся - винде звиздец

>Гвидо даже не нравиться выражение `print`. Его планируется заменить на функцию `write`.

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

>Сказано же, use list comprehensions. :) Хотя для особых фанатов, наверно, оставят и map, и filter, просто засунут в отдельный модуль.

Гвидо вообще подонак, вместо того чтобы сделать возможность писать несколько выражений в лямбде убирает его нафиг, ладно map и filter не жалко, они скорее всего будут отдельно, а вот за лямюду обидно. Лишний повод отказаться от питона в пользу руби.

> -- никаких принципиальных/фундаментальных изменений не будет.

Интересно, зачем тогда вообще это всё затевать? Получается, что обратную совместимость поломают, а принципиально нового ничего не сделают... А идею с выкидыванием "ненужных" фич Гвидо у гномовских девелоперов что ли подсмотрел? Не радует это всё :-/

люди на лоре читать не умеют. только писать.

ещё раз:

http://mail.python.org/pipermail/python-dev/2006-February/060415.html

так что лямбда пока что жива =)

P.S. вообще, товарищи, ознакомьтесь с pep-3000 & pep-3099 & pep-3100. и только после этого комментируйте новость. а то "мне мойша напел ..."

Да я увидил эту ссылку, уже после коммента... Хорошо что народ повлиял на Гвидо. Осталось только сделать её полноценной.

ГвидоВан молодец !!! Уважаю человека !!! Такой язык четкий придумал. Пусть дальше работает, может еще чо придумает.

Сказочник.

>Какое однако концептуальное изменение... Очень надеюсь, что так и сдохнет его Питон таким образом. Если человека посещают такие мысли, то лучше ему отказаться от программирования и отправится ловить бабочек на Суматру.

Что-то тут собачня разгавкалась, пора живодёров вызывать.

О проблемах с обратной совместимостью в python-2.x здесь врут и не краснеют. У меня немаленькое web-приложение, написанное во времена python-2.2, без вопросов работает на python-2.4. В самых тяжёлых случаях могут быть Deprecation Warning.

За "функциональщину" тоже бояться не надо. Generator expressions в python-2.4 - это ли не то, о чём мы все так мечтаем? Только ещё zip на itertools.izip заменить.

Только с лямбдой ситуация неоднозначная. IMHO, её вообще не надо было делать.

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

> У Гвидо четкая позиция - в языке не должно быть ничего лишнего

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

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

Вообще не понимаю зачем придумывать языки синтаксис которых отличный от Си ? Perl, Java, C# - понятно. Но проги на питоне выглядят просто ужасно и нечитабельно.

Господа, вот пример

def fn(i):
return i/2

a=3
b=3.0
if a==b:
print "3==3.0\n"
else
print "3!=3.0\n"

if fn(a)==fn(b):
print "3/2==3.0/2\n"
else
print "3/2!=3.0/2\n"


Всё. Функция принимает параметр-число, при этом
программист может передать ей и int и float и complex. При этом в примере a==b, хотя типы у них разные. Но результат у функции различен и зависит от типа параметра, но не от его значения.

Многие помнят об этом, когда пишут свои программы?

В Python 3.0 будет отдельный оператор деления и отдельный для деления с остатком, при этом "/" будет оператором "настоящего деления" (то есть будет a==b => fn(a)==fn(b), как и положено в математике).

Вот таких вот несовместимых исправлений там накопилось докучи.


Всем привет.

> Но проги на питоне выглядят просто ужасно и нечитабельно.

Это сначала так кажется. Немного поработав с ним, понимаешь что читабельности и элегантности у него как минимум не меньше, если не больше.

> Perl, Java, C# - понятно. Но проги на питоне выглядят просто ужасно и нечитабельно.

:)) Всё как раз наоборот. Синтаксис Python чище, и код на нём легче читается и понимается, особенно в сравнении с Perl. Всё дело в привычке просто.

> Типа увеличение производительности и всё такое. Допустим, если использовать python для расчётов (о ужас :-)

уже успешно используют, и без всякой компиляции. учи матчасть

> Всё. Функция принимает параметр-число, при этом программист может передать ей и int и float и complex.

а может и массив многомерный передать, или многочлен, или Decimal и что с того?

> При этом в примере a==b, хотя типы у них разные. Но результат у функции различен и зависит от типа параметра, но не от его значения.

как это не зависит от значения параметра? fn(10)==fn(20)?

> Многие помнят об этом, когда пишут свои программы?

все кому надо про целочисленное деление знают и в своих программах это учитывают.

и __future__.division появился уже в 2.3

> > Гвидо даже не нравиться выражение `print`. Его планируется заменить на функцию `write`.

> Какое однако концептуальное изменение... Очень надеюсь, что так и
> сдохнет его Питон таким образом. Если человека посещают такие мысли, то
> лучше ему отказаться от программирования и отправится ловить бабочек
> на Суматру.

Ознакомились бы сначала с сутью вопроса, а потом бы советы давали.
Было довольно детальное обоснование, почему это полезно.
Основные 2 причины:
1) часто print применяют для отладки программ. Когда/если программа вырастает, в какой-то момент возникает желание сделать logging более навороченным - писать в какой-нибудь файл, сделать лог более развернутым, менее развернутым, наконец, полностью отключить. print, как оператор, не требует наличия скобок вокруг аргументов, поэтому сделать просто текстовую замену print -> my_log_func не получится, придется править ручками или писать нетривиальный скрипт.
2) Опять же, print - оператор, а не функция, поэтому его не подашь передашь в другую функцию или lambda как аргумент.

А название решили сменить, чтобы было проще переходить, наверное.
Может, сделают параллельную поддержку print сначала.

И вообще, Python & GvR рулят, и, надеюсь, еще долго будут рулить.
Все наезжающие - в сад! :)

Заодно исчезнет не очень удачный синтаксис

print >> fd, "bla bla"

Надеюсь не додумаются до оператора cloaka_out вместо print

А к чему это "3000"? Плодить диалекты? Хрень какая-то. Я не согласен.

1) кого ####, согласен ты или нет? 2) Это свободный софт, дружок. Нравится тебе python2.3 или ядро 2.4 - сиди на них, в чем проблема-то?

> > Гвидо даже не нравиться выражение `print`. Его планируется заменить на функцию `write`.

> Какое однако концептуальное изменение... Очень надеюсь, что так и > сдохнет его Питон таким образом. Если человека посещают такие мысли, то > лучше ему отказаться от программирования и отправится ловить бабочек > на Суматру.

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

Призрак паскализма бродит по европе

> 1) часто print применяют для отладки программ. Когда/если программа вырастает, в какой-то момент возникает желание сделать logging более навороченным - писать в какой-нибудь файл, сделать лог более развернутым, менее развернутым, наконец, полностью отключить. print, как оператор, не требует наличия скобок вокруг аргументов, поэтому сделать просто текстовую замену print -> my_log_func не получится, придется править ручками или писать нетривиальный скрипт.

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

ну тут все наоборот, мне, например, ни разу не приходилось комментировать вроде // end if .. или // end for j и при этом никогда не возникало проблем с разделителями блоков:) Кометарии можно ставить вообще только для функций, код который писал год назад будет понятным даже с похмелья

19 апреля Гвидо выступал в Оксворде на тему Python 3000. Вот слайды: http://www.python.org/doc/essays/ppt/accu2006/Py3kACCU.ppt