Вышла альфа Python 3.0

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

Вот это:

- новый синтаксис форматирования строк, метод .format вместо оператора "%";

и это:

- деление целых теперь даёт вещественный результат;

думаю приведет к геморою

> - деление целых теперь даёт вещественный результат; > > думаю приведет к геморою

нет! к геморою приводит постоянная необходимость добавлять .0 к числовым литералам. Тем более, что целочисленное деление не отменяется. Для этого есть оператор //

> .format вместо оператора "%"

'My name is %s, I am %i years old' % ('Vasia', 13)

'My name is %s, I am %i years old'.format('Vasia', 13)

Велика ли разница?

>В то время как PHP 6 и Perl 6 всё ещё маячат в туманных горизонтах, уже вышла первая альфа Python 3.0 (проект, ранее известный как Python3000).

А оно ещё нужно кому-то? Есть же Ruby.

>Тут не понял :( Пойду почитаю.

>> Не говоря уже о том, что unit-тесты редко дают 100%-coverage.

>Есть проблема, но она к необязательному описанию полей она по-моему не относится напрямую :(

простой пример:

if a == 100: some1 = obj.fld1 else: some1 = obj.fl2 # неправильно, нужно fld2

Вот опасности необязательного описания полей в условиях не-100% coverage. Представь, что атрибут не читаетс, а записывается.

>Велика ли разница?

да, писать больше

Ну в C например от этого никто еще умер

старые скрипты придется переделывать

> да, писать больше

На целых 4 символа. Зато читать и понимать проще. И не надо больше ломать голову, при чём тут оператор остатка от деления нацело.

> Вот опасности необязательного описания полей в условиях не-100% coverage.

Ну я могу написать и

if a == 100: some1 = obj.fld1 else: some1 = obj.fld1 # превед! :)

В этом случае при отсуивии должного теста я спокойно обманул обязательное описание полей.

> Ну я могу написать и

> if a == 100: some1 = obj.fld1 else: some1 = obj.fld1 # превед! :)

Я что - сказал, что юнит-тесты не нужны?

> Я что - сказал, что юнит-тесты не нужны?

Причем в условиях аутокомплишн мой случай вероятнее, чем появление нового поля.

> аутокомплишн

Яйца отрезайшн экзекюшин?

у него хоть одна версия новая была совместима со старой? сколько помню всегда во всех дистрах зооопарк

2.0-2.2 2.2-2.4 2.4-2.5 итп

> в условиях аутокомплишн мой случай вероятнее, чем появление нового поля.

Я привел самый тривиальный случай. Против передачи параметра неправильного типа в функцию (тоже под условием) autocompletion не спасет.

Да.. Python 3K рулёд

>- деление целых теперь даёт вещественный результат;

А вот это зря имхо..

> у него хоть одна версия новая была совместима со старой?

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

> Велика ли разница?

'My name is %s, I am %i years old' % ('Vasia', 13)

'My name is {0}, I am {1} years old'.format('Vasia', 13)

Вот так, на самом деле.

2tailguuner Ну как не понятно, Python использует утиную типизацию. Кроме того мы даже можем писать в стиле

if cfg.flag: def aaa(): print "Version 1" else: def aaa(): print "Version 2" aaa()

Тоесть на чашу весов поставили а) глупые ошибки типа опечаток б) значительные удобства начиная с облегченного миксинга обьектов и т.д.

Так, что это просто дело вкуса. Вам уже сказали, что и разбор XML и INI файлов в таком виде в разы удобнее. Да и еще в множестве случаев Посмотрите как Jabber bot подымает команды

for i in globals().keys(): if i[-7:]=='Handler' and i[:-7].lower()==i[:-7]: commands[i[:-7]]=globals()[i]

А теперь сделайте это на C++, прийдется писать целую систему плагинов

> 2tailguuner Ну как не понятно, Python использует утиную типизацию.

А Волга впадает в Каспийское море.

> Кроме того мы даже можем писать в стиле

Дружище, я всё это знаю - пользуюсь Питоном уже лет 5.

> Тоесть на чашу весов поставили а) глупые ошибки типа опечаток

То есть дальше моего тривиального примера ты не видишь? Жаль.

> б) значительные удобства начиная с облегченного миксинга обьектов и т.д. Так, что это просто дело вкуса

"Giving people dynamic languages doesn't mean they write dynamic programs" -- увидено на LtU

> for i in globals().keys(): if i[-7:]=='Handler' and i[:-7].lower()==i[:-7]: commands[i[:-7]]=globals()[i]

> А теперь сделайте это на C++, прийдется писать целую систему плагинов

Аха, а еще я умею писАть самомодифицирующийся код на ассемблере.

>>'My name is %s, I am %i years old' % ('Vasia', 13) >>'My name is %s, I am %i years old'.format('Vasia', 13) >>Велика ли разница?

чем меньше разношерстного синтаксиса тем меньше ошибок.

> for i in globals().keys(): if i[-7:]=='Handler' and i[:-7].lower()==i[:-7]: commands[i[:-7]]=globals()[i]

Ужасный код.

Лучше так:

for func_name, func in globals().items():
    if func_name.endswith('Handler'):
        name = func_name.rstrip('Handler')
        if name.islower():
            command[name] = func

Скачал, попробовал. Из того, что бросилось в глаза: 1) форматирование через % по-прежнему работает

>>> "%s %s" % (b'123', "qq") '123 qq'

2) А вот в IDLE как-то не так стала работать функция help - открывает почему-то консоль с хелпом, вместо-того чтоб писать в IDLE.

В целом, изменения очень правильные, особенно что касается строк.

PHP6 в туманых горизонтах? Сходите на snaps.php.net и скачайте себе альфу PHP6, она там уже очень долго лежит.

> Сходите на snaps.php.net и скачайте себе альфу PHP6, она там уже очень долго лежит.

Эмм... с какой стати обычный непонятный снэпшот называть альфой?

> - новый синтаксис форматирования строк, метод .format вместо оператора "%";

Гвидо последователен в своем стремлении сделать чистый синтаксис с использованием функций, а не хитрых операторов. За это ему респект.

> Хорошая проповедь тута: http://live.julik.nl/2005/12/composition-normalization-and-morons

я так понял, что utf-8 это все-равно костыль, а труъ только utf-16

> Ура. Теперь ждем беты Ruby 2.0, и смотрим, как же оба сообщества решат вопрос с реализацией потоков (нативно, green threading, еще как-то -- у каждого подхода хватает своих минусов). Хотя было бы очень интересно увидеть-таки оживление разработки Perl 6, боюсь, в будущее мы пойдем все же под знаменами Python и Ruby.

в svn у ruby 1.9 потоки нативные сейчас.

но юникода пока нет :(

>В то время как PHP 6 и Perl 6 всё ещё маячат в туманных горизонтах, уже
вышла первая альфа Python 3.0 (проект, ранее известный как Python3000).

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

niemand@gloom:~$ apt-cache search pugs
libghc6-pugs-dev - Pugs haskell interface
pugs - Perl 6 Implementation
pugs-doc - Pugs documentation
pugs-modules - Pugs core modules

> C.a = 1
> где а - переменная не объявленная в классе, то она будет автоматически создана?

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

>>> class CC(object):
...     __slots__ = ('b', 'c')
...     def __init__(self):
...             self.b = 1
...
>>> C = CC()
>>> C.b = 2
>>> C.a = 1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'CC' object has no attribute 'a'
>>>

> На счет "Да, конечно будет создан. А что?". По-моему это очень не удобно, когда переменные создаются сами собой в любом месте кода. Это подходит для маленьких скриптов, но совершенно недопустимо для больших программ.

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

> я так понял, что utf-8 это все-равно костыль, а труъ только utf-16

Совсем тру - это UCS-4. Но обычно питон собирают таки в UTF-16, виндовый дистрибутив именно такой.

> Ну не надо примеры притягивать за уши. В данном случае можно использовать ассоциативный массив.

Не всегда. Хотя бы потому, что для работы с этим массивом придется приделывать доп. средства. А так - все, "сказанное" для "родных" атрибутов, оказывается справедливым и для вновь приобретенных. И *объектно*-ориентированный подход становится, наконец, по-настоящему *объектно*-, а не *класс*-ориентированным.

Простой пример, по мотивам классического введения в ООП, про яблоко:

Вот, у нас есть класс, описывающий яблоко: сорт, размер, цвет кожуры, вкус итп. Есть объект этого класса, представляющий, так сказать, отображение реального яблока в нашу программную действительность. В реальное яблоко забирается червяк. Какие действия вы предпримете, чтобы описать изменившуюся ситуацию, а именно, наличие червивого яблока? В "статических ООП языках" проблема тянет на создание класса-наследника "Червивое яблоко": все, то же самое, что и для настоящего яблока, но теперь с червяком. Класс "ящик" нужно проверить на предмет того, что он точно в состоянии хранить, как обычные, так и червивые яблоки, а потом все существующие ящики преобразовать, если нужно, в обновленные, "для червивых яблок".

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

А если серьёзно, то я, конечно, стараюсь не злоупотреблять "динамичностью" питона. Однако, и мне пару раз реально требовалось в динамике добавить доп. методы, правда, не к объектам, а к классам.

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

А кому сейчас легко ;-)

>Все совместимы. Зоопарк был связан с неумением маинтайнеров дистрибутивов разобраться с обновлениями бублиотек.

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

>я так понял, что utf-8 это все-равно костыль, а труъ только utf-16

Тру, не тру, но utf-8 сегодня намного более стандарт, чем что-либо ещё.

>>> 7/3 == -(-7/3)
True

Да, он сделал это! Браво, Питоша. Хотя для своих целей я уже отполз на lua и lisp. Но для dirty and quick программулек Питон самое то.

>> Ну не надо примеры притягивать за уши. В данном случае можно использовать ассоциативный массив.

>Не всегда.

"Можно" - всегда. Другое дело, что можно и производный класс создать.

> И *объектно*-ориентированный подход становится, наконец, по-настоящему *объектно*-, а не *класс*-ориентированным.

...а программа может стать невразумительной кашей.

> Простой пример, по мотивам классического введения в ООП, про яблоко:

[вкусный и полезный пример про яблоко поскипан]

> А если серьёзно, то я, конечно, стараюсь не злоупотреблять "динамичностью" питона. Однако, и мне пару раз реально требовалось

Вот именно - "пару раз". А разговоров о динамизме, примеров про яблоки - ну просто килограммы :) Повторю: "giving people dynamic languages doesn't mean they write dynamic programs" -- (c) кто-то с LtU.

> И ваще, ставить перл в одну строку с быдлоподелиями пхп и питон не надо,

А вот и перлисты подтянулись в ветку о Питоне 8) Добро пожаловать, братишка! :D

Даёшь флейм!

> Но для dirty and quick программулек Питон самое то.

Для этого есть perl ;)

> Велика ли разница?

А во что превратится

'My name is %(name)s, I am %(age)i years old' % {'name: 'Vasia', 'age' : 13}

?

Честно говоря, с процентом было изячнее...

> Честно говоря, с процентом было изячнее...

Может, вернут в 3.1 8)

> 'My name is %(name)s, I am %(age)i years old' % {'name: 'Vasia', 'age' : 13}

'My name is {name}, I am {age} years old'.format(name='Vasia', age=13)

Намного красивее! К тому же унификация - функция вместо загадочного оператора. Тут же не мрачный перл. Все правильно делают.

>Намного красивее! К тому же унификация - функция вместо загадочного оператора. Тут же не мрачный перл. Все правильно делают.

на перле ведь еще красивее, почему он мрачный я не понял

"My name is $name, I am $age years old"

и вдобавок в полтора раза короче

>на перле ведь еще красивее ... и вдобавок в полтора раза короче

Это только иногда.
1. часто всё равно приходится писать "${name}", т.ч. "{name}" - лучше.
2. напиши на перле повторное использование шаблона (с другими значениями)

...
tmpl='my name is {user.name}, my age is {user.age}'.format
tmpl(user=user1)
tmpl(user=user2)
...

Потом и посмотрим кто окажется короче. Почему-то мне кажется, получим то же: в перле удобнее и короче "одноразовые" и тривиальные случаи.

foreach(array("name1"=>"age1", "name2"=>"age2") as $name->$age)
    echo "my name is {$name}, my age is {$age}";

Но за такое яйца надо отрывать. Хоть в PHP, хоть в Ruby.
Засовывание View в Controller. И эти люди ещё что-то о ПХП говорить будут? :D

А, да, торможу, там же не только View и Contoller, но ещё и Model :D В общем - полный перлец :D

С какой радости? View и Model вполне может быть вынесена "внаружу".

Ну и плюс, "не надо делать из еды культа". Чрезмерно упорядоченные фреймворки оказываются слишком нудными для применения, увы.

> Вот именно - "пару раз". А разговоров о динамизме, примеров про яблоки - ну просто килограммы :) Повторю: "giving people dynamic languages doesn't mean they write dynamic programs" -- (c) кто-то с LtU.

Ну, зато в этой паре раз без динамики было бы совсем неуютно. К тому же, некоторые фреймворки используют динамику "под капотом", соответственно, ты сам, вроде как пишешь "статически", но без динамики это вообще "не едет".

>foreach(array(

По правде я ожидал что-то типа(перл забыл, т.ч. извините за ошибки)

sub tmpl() { return "my name is ${{$0}->name}, my age is ${{$[0]}->age}"; }

Что уже процентов на 20 длиннее и довольно сильно замусорено.