Вышел Python 3.1

> Класс для хранения упорядоченных словарных данных.

Клёво, надеюсь это заюзают в web.py.

> после чего можно писать
>
> o = rec(coord=rec(x=1,y=2),v=3)
>
> o.coord.x
> o.v
>
> и т. д.

man ctypes? И в качестве бонуса - поддержка битовых полей! (:

>man ctypes? И в качестве бонуса - поддержка битовых полей! (:

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

> man ctypes?

это совсем из другой оперы.

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

все эти вещи зависят не от ЯП, а от того, откуда руки произростают. Хреновому программеру всегда, то нехватает чего-то, то мешает что-то :)

Судя по вашим лозунгам, вы все больше по процедурному программированию выступаете, и объекты понимаете весьма превратно ;)

Естественно, быстро, ибо одной и той же переменной присваиваешь.

Вот такой пример попробуй:

class Struct:
field1 = True
field2 = False

a = []
for x in range(1000000):
a.append(Struct())

Бетон не нужен, Делфи - наше все!

> А теперь, толстячок, по пунктам, чем это "лучше"?

Да хотя бы вот этим:

void foo() {
    try {
        do();
    } catch { throw; }
}

> Вот такой пример попробуй:

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

>Сейчас присматриваюсь к разным скриптовым языкам для JVM.

посмотрите на Groovy

>>man ctypes? И в качестве бонуса - поддержка битовых полей! (:

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

А потери откуда?

> посмотрите на Groovy

говорят он говёный и что жруби даже лучче

>Да ну?! Сразу видно, что кульхацкеры с ЛОРа ничего, кроме хелловорда реально не пейсали.

Я писал. Манифестировать типы переменных не нужно.

>Ждём раскрутки D.

Не ждем.

>Нет. Мне подходит SWT. Для Cocoa. Чтобы 100% HIG был.

Дался тебе этот HIG. Что такое хорошо, что такое плохо каждый человек должен хавать самостоятельно, а не сверяясь со справочником.

>Может главное сопровождение кода, скорость разработки и прототипирования и т.п.?

Так вот у динамической она ниже.

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

Не гони.

>> Может главное сопровождение кода, скорость разработки и прототипирования и т.п.?

> Так вот у динамической она ниже.

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

>А ты проверь. У меня ничего не жрёт и работает быстро.
>for x in range(1000000):
> struct = Struct()

Мистика да? А так?

> python

12812 4932 0:00.02 0 0.1 20 0 S 27828 22m 4856 1000 python

>>> s = []
>>> for x in range(1000000):
... s.append(Struct())

12812 4932 0:08.14 0 9.6 20 0 S 405m 24m 381m 1000 python

???

>Dictionary тебя разве не спасёт? Пусть имена полей будут индексами в ассоциативном массиве.

Мы в 21 веке, не?

>говорят он говёный и что жруби даже лучче

Наоборот разве что.

>Если бы это было так, то динамически типизированные языки давно бы вымерли.

С какой радости? Жигули всегда были медленее феррари. Они то конечно вымерли, но ты ж понимаешь.

>>> Может главное сопровождение кода, скорость разработки и прототипирования и т.п.?

>> Если бы это было так, то динамически типизированные языки давно бы вымерли.

> С какой радости?

Потому что у них не было бы вообще никаких преимуществ по сравнению со статикой.

> Жигули всегда были медленее феррари

Аналогии такие аналогии.

>Потому что у них не было бы вообще никаких преимуществ по сравнению со статикой.

Это если бы типизация языков была этонашевсе. А оно не есть. Но я тут больше про совпровождение кода и менше про прототипирование.

> Питон память в разы меньше расходует.

Питон сожрал на миллион указанных структур 381 метр. Жаба 50m.

public class ExampleProgram {
   public static class Struct{
                public boolean field1 = true;
                public boolean field2 = false;
   }
  public static strictfp void main(String[] args) throws Exception{
                System.in.read();
                java.util.ArrayList<Struct> l = new java.util.ArrayList<Struct>();
                for(int i=0; i< 1000000; i++) l.add(new Struct());
                System.out.println("done");
                System.in.read();
  }
}

>> Питон память в разы меньше расходует.

> Питон сожрал на миллион указанных структур 381 метр. Жаба 50m.

newstyle class, __slots__ - и Питон занимает 55метров на тот же миллион.

>newstyle class, __slots__ - и Питон занимает 55метров на тот же миллион.

Да нихто ж не против - я про то что питон жрет меньше чем жаба. Не меньше.

> Да нихто ж не против - я про то что питон жрет меньше чем жаба. Не меньше.

[зевая] синтетические тесты свои можете запихнуть куда угодно. Лучше покрутите по очереди Deluge и Vuze, и посмотрите сколько они сравнительно хавают.

> Да нихто ж не против - я про то что питон жрет меньше чем жаба. Не меньше.

А если уж хочется синтетических тестов - то вот, ничем не хуже:

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=java&a...

> я про то что питон жрет меньше чем жаба. Не меньше.

Это смотря как считать - фиксированный стартовый оверхэд у Питона в разы меньше.

>Лучше покрутите по очереди Deluge и Vuze, и посмотрите сколько они сравнительно хавают.

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

.А если уж хочется синтетических тестов - то вот, ничем не хуже:

Кроме того что там тест сначала на перфоманс а потм уже на мемори юс? Да конечно в 300 раз слить по скорости и в 3 раза выиграть по памяти очень почетно.

>Это смотря как считать - фиксированный стартовый оверхэд у Питона в разы меньше.

сопудова. Умеет он тоже при этом в разы меньше.

>> Это смотря как считать - фиксированный стартовый оверхэд у Питона в разы меньше.

> сопудова. Умеет он тоже при этом в разы меньше.

Ненене, это для хелловорлда. То, что "умеет в разы больше", имеет оверхэд, больший на порядки %)

>Ненене, это для хелловорлда. То, что "умеет в разы больше", имеет оверхэд, больший на порядки %)

Ненене - для хеловорлда работают все те же механизмы, что и для того этого.

Не слушайте их. И уж явно groovy лучше jython'

> Питон сожрал на миллион указанных структур 381 метр. Жаба 50m.

Хмм...
вот такая программа -

import sys

class Struct(object):
    __slots__ = ( 'field1', 'field2' )
    def __init__(self):
        self.field1 = True
        self.field2 = False

N = 1000000

sys.stdin.readline()

l = [ Struct() for i in xrange(N) ]

print 'done'
sys.stdin.readline()

у меня по данным top (s: DATA = Data+Stack size (kb)) требует 37 метров.

Python 2.5.2, Ubuntu 8.04.3, 32 bit

В чём фокус? :)

> для хеловорлда работают все те же механизмы

Тольк в хелловорлде на входе у этих механизмов на порядок меньше данных (== библиотек).

>В чём фокус? :)

RES = 75m DATA=74m

Python 2.6 (r26:66714, Feb 3 2009, 20:49:49)
[GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2
Linux r 2.6.27.23-0.1-default #1 SMP 2009-05-26 17:02:05 -0400 x86_64 x86_64 x86_64 GNU/Linux

>Тольк в хелловорлде на входе у этих механизмов на порядок меньше данных (== библиотек).

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

Ну то есть вот в этом: x86_64

Питон под x64 кушает в два раза больше памяти похоже.

>Питон под x64 кушает в два раза больше памяти похоже.

И не только он один.

> Не слушайте их. И уж явно groovy лучше jython'

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

Интересен JRuby, но как-то напрягает несовсем естественная интеграция с java. На рассмотрении еще Rhino (JavaScript) и Jython.

Ты, видать, из тех, кто уверен, что кроме жабы ничего в этом мире нет :)

>Ты, видать, из тех, кто уверен, что кроме жабы ничего в этом мире нет :)

.NET не нужен.

> Питон под x64 кушает в два раза больше памяти похоже.

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

>>> class A:
... __slots__ = ('p','x')
...
>>> class B(object):
... __slots__ = ('p','x')
...
>>> class C:
... pass
...
>>> c = C()
>>> b = B()
>>> a = A()
>>> c.y = 5
>>> b.y = 5
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'B' object has no attribute 'y'
>>> a.y = 5


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

> У меня одного такое ощущение, что все майнстрим языки нуждаются в существенном редизаяне вплоть до обратнонесовместимого?

Новые придумывай.

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

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

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