Вышел Python 3.1

> Педон не имеет строгой статической типизации. На отсутствии строгой типизации погорел смолток. Для enterpriZe нужен язык со (1) строгой (2) полиморфной (3) статической (4) безопасной (5)именованной (6) явной типизацией, а не пионЭрское поделие.

Это говорят души отправленных в биореактор?

Нет, просто задача стоит выбрать скриптовый язык именно под JVM.

>> P.S. в Питоне 3.x приведенная тобой фигня исправлена.

> В какую сторону?

В правильную же.

> Нет, просто задача стоит выбрать скриптовый язык именно под JVM.

Занеси еще Boo в чеклист.

>Занеси еще Boo в чеклист.

Это уже не JVM.

Хотя скорость его поражает...

>> Занеси еще Boo в чеклист.

> Это уже не JVM.

Ч0рт, я вечно путаю все эти модные VM. Конечно, он для .NET, не для JVM.

> Хотя скорость его поражает...

Он же наполовину статический.

>В правильную же.

в экземпляры со слотами можно декларировать новые аттрибуты?

> в экземпляры со слотами можно декларировать новые аттрибуты?

Насчет "декларировать" - не понял. Присваивать атрибутам, отсуствующим в __slots__, нельзя (но можно не задавать __slots__). Обычная семантика newstyle-классов Питона 2.2+

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

хм, не замечал, но я только с версии 1.5 с ним работал. Хотя я не очень понимаю, что подразумевается под "какой-то разгильдяйский и непоследовательный в синтаксисе"

>Интересен JRuby, но как-то напрягает несовсем естественная интеграция с java.

у groovy интеграция с java лучше всех, даже лучше JavaFX.

>На рассмотрении еще Rhino (JavaScript) и Jython.

если нет строгого требования использования js/python для скриптования, groovy намного круче. Собственно, из все JVM-based _скриптовых_ языков с groovy по распространённости, комьюнити, поддержке и развитию сравниться может разве что jruby, да и к нему имхо даже сан теряет интерес.

То есть все вот так?

>>> class B(object):
... __slots__ = ['p','x']
...
>>> b = B()
>>> b.__slots__
['p', 'x']
>>> b.__slots__.append('c')
>>> b.__slots__
['p', 'x', 'c']
>>> b.c = 4
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'B' object has no attribute 'c'

То есть в рантайме нельзя ничего в класс подсунуть?

> То есть в рантайме нельзя ничего в класс подсунуть?

Нельзя, если определён __slots__.

> .NET не нужен.

Тем не менее, C# лучше жабы.

>> Хотя скорость его поражает...

>Он же наполовину статический.

Как это наполовину? Разве не полностью? Он же тот же си-шарп, только с пайтоноподобным синтаксисом. Мелкософтовский CLI же.

>Он же наполовину статический.

Полностью (в рамках .NET, конечно). Всё равно поражает. В некоторых тестах работает быстрее, чем C# (и быстрее heap-кода в Си++).

>> Он же наполовину статический.

> Полностью

Я бы не назвал язык, в котором есть "as duck", полностью статическим.

Привет. Это называется "выведение типа".

> Привет.

И тебе привет.

> Это называется "выведение типа".

Это так не называется.

http://boo.codehaus.org/Duck+Typing

>Я бы не назвал язык, в котором есть "as duck", полностью статическим.

Утиная типизация - частный случай статической. Просто типы не программист расставляет, а компилятор.

> Утиная типизация - частный случай статической.

ыыыы... Ну от тебя я такого не ожидал %)

"if you declare an object as type duck or cast to type duck (or turn on the implicit duck typing option, see below), then boo will not try to resolve any methods or operations you call on that object at compile time. Instead it will convert those operations into methods that do not resolve until runtime" - если это статическая типизация, то что такое динамическая типизация?

Цитирую первую строчку: "Boo is a statically typed language, like Java or C#."

Однако, согласен, там есть нечто вроде void-типа (не знал).

> Цитирую первую строчку: "Boo is a statically typed language, like Java or C#."

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

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

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

>если это статическая типизация, то что такое динамическая типизация?

Утиная типизация может быть динамической, может быть статической. В boo - она статическая :)

...

При статической типизации все типы выводятся на этапе компиляции и связывание методов осуществляется прямое.

При динамической - типы выводятся в рантайме и связывание идёт косвенное.

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

В обычных языках падает на порядок.

На Форте как-то делал реализацию динамики с потерей около 30% производительности. Но там динамика была не совсем честная :) Т.е. в работе - динамика чистая. Но на практике каждый класс тащил с собой виртуальную таблицу с ячейками для _всех_ динамических методов всех классов. На среднем проекте это могло выливаться в килобайты данных на каждый класс, на большом - в десятки килобайт. По тем временам расход был приличный :)

> Утиная типизация может быть динамической, может быть статической.

Это новое слово в языкознании.

> При динамической - типы выводятся в рантайме и связывание идёт косвенное.

Повторю цитату: "boo will not try to resolve any methods or operations you call on that object at compile time. Instead it will convert those operations into methods that do not resolve until runtime".

> Утиная типизация может быть динамической, может быть статической.

Грязная, наглая ложь :]

Типизация бывает статическая, выводимая (inference) и динамическая (она же утиная). Последние две не стоит путать.

"var" в C#, "auto" в D - это выводимая

"duck" в Boo - это динамическая

Упс. Пардон, слажал-с.

Я устройство утиной типизации перепутал с Хиндли-Миллером :)

Гы. И вот, наверное, откуда корни моей ошибки лезут - в Вики сказано, что в Boo юзается как раз Хиндли-Милнер.

> в Вики сказано, что в Boo юзается как раз Хиндли-Милнер.

Там юзается всё - и явное объявление, и вывод типов, и динамическая типизация.

> Тем не менее, C# лучше жабы.

Что значит "лучше"? Java - консервантивный язык, туда новых фич неподумав не добавляют. C# же делают по принципу "добавим в язык всяких модных штук, чтобы быдлокодеры радовались". И в любом случае, "Java-платформа vs .NET" - это не "язык Java vs C#". Не хватает почему-то возможностей языка Java - пишите на Scala, например.

> Хотя я не очень понимаю, что подразумевается под "какой-то разгильдяйский и непоследовательный в синтаксисе"

Например, странная конструкция для передачи замыканий в конструктор вместе с необязательностью использования ';' создает такие вот неочевидные вещи:

def t = new Thread()
{
println "x"
}

Что в { } - замыкание, передаваемое в конструктор Thread, или самостоятельный блок кода следующий уже после конструктора? Понятно, что в спецификации этот случай рассмотрен, но это и есть непоследовательность, ухудшающая читабельность кода. Кроме того, эта конструкция похожа на объявление анонимного класса в Java. Если анонимные классы добавят в Groovy, как они будут объявляться?

>Что в { } - замыкание, передаваемое в конструктор Thread, или самостоятельный блок кода следующий уже после конструктора?

ээ.. передача данных в конструктор - это

def t = new Thread({
println "x"
})
причём замыкание тут - это (не)явная реализация единственного метода в интерфейсе Runnable.

>Если анонимные классы добавят в Groovy, как они будут объявляться?

а зачем они в groovy?

> ээ.. передача данных в конструктор - это

Это альтернативный синтаксис для того же самого. Зачем-то поддерживаются оба способа.

> а зачем они в groovy?

Для реализации интерфейсов из нескольких методов.

>Это альтернативный синтаксис для того же самого. Зачем-то поддерживаются оба способа.
ээ.. у меня работает только так:

def t = new Thread(){
println "x"
}

вот так - даже не компиляется:

def t = new Thread()
{
println "x"
}

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

Может, это связано с тем, что Sun - бакланы, которые просрали свой бизнес?

> C# же делают по принципу "добавим в язык всяких модных штук, чтобы быдлокодеры радовались".

Вы вроде как пытаетесь намутить противопоставление, но сказать что фичи в шарп добавляют "не подумав" - у вас ведь язык не повернётся, м?

> Не хватает почему-то возможностей языка Java - пишите на Scala, например.

Есть некоторая разница между флагманским продуктом крупной корпорации и пионэрскими поделками - в стабильности, инструментарии, документированности.

> вот так - даже не компиляется:

У меня компилится (groovyc), но не запускается. Ошибка очень странная:

Caught: groovy.lang.MissingMethodException: No signature of method: java.lang.Thread.call() is applicable for argument types: (test$_run_closure1) values: [test$_run_closure1@9931579]

И это не соответствует документации:
http://groovy.codehaus.org/Differences+from+Java#DifferencesfromJava-Uncommon...

Если поместить это объявление в тело класса, как в примере по ссылке, вылетает та же ошибка, только при создании экземпляра класса.

> Может, это связано с тем, что Sun - бакланы, которые просрали свой бизнес?

Это связано с тем, что над Java работают серьезные люди, такие как Гослинг. А финансово успешными часто становятся наименее этичные компании.

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

Я бы сказал "мало подумав".

> Есть некоторая разница между флагманским продуктом крупной корпорации и пионэрскими поделками - в стабильности, инструментарии, документированности.

Есть конкретные претензии к Scala?

> А ты проверь. У меня ничего не жрёт и работает быстро.

> for x in range(1000000):
> struct = Struct()

может быть, потому что ты не знаешь, что делает range()?

> может быть, потому что ты не знаешь, что делает range()?

Это ты не знаешь. rtfm http://docs.python.org/3.1/library/functions.html

сколько пафоса и самоуверенности.
то, что ты написал в качестве примера, не может занимать много памяти в силу внутреннего устройства питона и наличия у него gc. ты знаком с понятием генератора? так вот, начиная с какой-то там версии питона (лень искать, с какой, недавно), range возвращает генератор. это значит, что в памяти не создается полного списка, его элементы получаются последовательным вызовом метода генератора. что и делает оператор фор при каждой итерации. так что лишняя память тут не занимается, только под один объект-число.
тот факт, что ты при каждой итерации создаешь новый объект класса struct, и записываешь ссылку на него (ты ведь знаешь, что это, правда?) в одну и ту же переменную, то есть теряешь последнюю ссылку на предыдущий struct, позволяет сборщику мусора сразу же убрать за тобой, освободив занимаемую предыдущим объектом память.
в сущности, твой пример абсолютно не показателен. я, вообщем-то, согласен с тем, что питон достаточно аккуратен с памятью, я вообще его сторонник, но ты выставил себя в нелестном свете. впредь будь аккуратнее с высказываниями, проверяй свою информацию, и не обзывай собеседником неучами раньше времени - вежливость может сослужить неплохую службу.

и да - да здравствует новый питон! ура!

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

Во-во, это всё к тебе относится к тебе, а не ко мне. Ты первый начал с обвинений при этом не ознакомившись с тредом ( http://www.linux.org.ru/view-message.jsp?msgid=3825320&page=2#3828628 ).

Собстно я и не отрициаю что я хреновый программист, но уверен ли ты что ты прогаешь лучше?

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

> Ты первый начал с обвинений при этом не ознакомившись с тредом ( http://www.linux.org.ru/view-message.jsp?msgid=3825320&page=2#3828628 ).
я не начинал никаких обвинений. я указал на твою ошибку в интерпретации результатов теста, тобой же составленного. тебе не понравилась форма? мне кажется, она вполне корректна.
> может быть, потому что ты не знаешь, что делает range()?

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

> Зная твою неприязнь ко мне извинений за оскорбления от тебя не жду.
неприязни к тебе у меня нет, ты иногда даешь дельные замечания и советы новичкам. оскорблений не было, извинений не последует исключительно по этой причине. ты ткнул меня носом в ман, не удосужившись разобраться в сути вопроса. мне такое обидно, знаешь ли. я почему-то считаю, что за науку нужно быть благодарным, а не кидаться с фразами "нет, ты!".

если я не прав, то охотно признаю свою неправоту и извинюсь. в том числе и за тон.


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

>>> with open('mylog.txt') as infile, open('a.out', 'w') as outfile:
... for line in infile:
... if '<critical>' in line:
... outfile.write(line)

Так это ты начал с наезда что я не знаю как работает range. И не объяснил в чём я, по-твоему, ошибаюсь. Просто сказал что я нифига не понимаю. Ты не находишь что это нельзя назвать конструктивной критикой?

> ты ткнул меня носом в ман

а ты меня никуда не ткнул, это ещё хуже.

Так в чём ошибка-то? Запустил тест time { python3 ./test.py; }, посмотрел время исполнения и сделал выводы на счёт скорости. Паралельно по ps awwux посмотрел скока памяти жрёт. Сделал выводы и высказал их. Т.к. речь шла больше о скорости а не о памяти то сохранение в списке я выкинул из примера что особо никак не сказалось на производительности. Да, формально надо было список оставить, но я решил не загромождать пример.

боже. я же уже все написал тут http://www.linux.org.ru/jump-message.jsp?msgid=3825320&cid=3833543

> Запустил тест time { python3 ./test.py; }, посмотрел время исполнения и сделал выводы на счёт скорости. Паралельно по ps awwux посмотрел скока памяти жрёт. Сделал выводы и высказал их.

ты прочитай еще раз, о чем шла речь:

> но у него есть недостатки. тупль - просто несколько объектов склеенных, типа структуры в C. А твой Struct (и мой rec) - объект, со своим словарем который хранится с каждый объектом. Если таких объектов много то это будет жрать память в несколько раз больеш чем надо.

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

то есть, речь шла о "перерасходе" памяти по сравнению с голой структурой и большем времени доступа по сравнению с чтением через указатель+смещение.
твой тест просто создает объекты одного и того же класса, при чем в памяти одновременно хранится только один. никаких процедур с этим объектом, кроме создания и удаления не производится. что показал твой тест? сравнительный расход памяти? скорость доступа к полям и/или методам объекта? нет. только то, что "у меня работает быстро и памяти много не жрет". я объяснил, почему так.
выходит, что дело не в том, что ты ошибся в тесте. ты ошибся в выводах, они _ничего_ не значат и не показывают.

Да я же говорю, я два варианта теста гонял. Вот первый:

$ cat ./test.py 
class Struct:
    field1 = True
    field2 = False


structs = []
for x in range(1000000):
    struct = Struct()
    struct.field1 = False
    structs.append(struct)

print("Done. press enter to exit.")
input()
(тут смотрим ps awwux | grep python3 и смотрим скока жрёт памяти)
$ ps awwux | grep python3
test  11253 65.7  9.7 198056 194972 pts/13  S+   13:40   0:05 python3 ./test.py


Второй тест на _скорость_ создания, удаления и работы со "структурами". Спецально выкинул работу со списком, он ощутимо тормозит. Именно про это я и писал.

$ cat ./test2.py 
class Struct:
    field1 = True
    field2 = False


for x in range(1000000):
    struct = Struct()
    struct.field1 = False

$ time { python3 ./test2.py;  }
[24574 refs]

real    0m1.907s
user    0m1.900s
sys     0m0.010s


По результатам тестов я и написал что всё работает достаточно быстро. Тесты примитивные и тупые, но оценить оверхед позволяют. Что тебе в них не нравится?

во-первых, _где_ ты это писал? дай ссылку на конкретное сообщение, а?

во-вторых, что ж ты для первого теста приводишь использование памяти, а для второго время исполнения? на моем компьютере:
первый тест. VSZ 406648, RSS 389248, real 0m23.974s, user 0m9.985s, sys 0m0.468s
второй тест. VSZ 43344, RSS 27608, real 0m3.705s, user 0m0.968s, sys 0m0.036s
из обоих тестов следует вычесть секунды по две на выполнение ps | grep в другой консоли, то есть время не очень точное. тем не менее, результат на лицо, но это все равно ничегошеньки не показывает ;)

в-третьих, твой тест все равно не сравнивает скорость работы и потребление памяти при работе с объектом и "голой" структурой.

а что, собственно, твой тест сравнивает? можешь сформулировать?

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

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

Мир? :)