Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, eugals, Вы писали:

E>>А теперь то же самое с использованием возможностей питона 2.4:
E>>

E>>file("out.txt", "w").writelines(sorted(file("test.txt")))
E>>

Т>Чисто для прикола:
Т>

Т>"out.txt" 0: t[<t: 0: "text.txt"]
Т>

Ruby?
По моему питон читабельней, хотя Ruby тоже не плох

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, FR, Вы писали:
FR>>Не надо по деревьям лазить, достаточно брать любую небольшую утилитку активно работающую с текстовыми файлами, объем кода будет сильно меньше чем на плюсах или шарпе, близко к объему на перле, но в отличии от перла не write-only а вполне читабельный код.
S>Угу. А вот при рисовании линий на экране лого порвет этот ваш питон как тузик грелку.

from turtle import *

clear()
forward(40)
left(90)
forward(40)
left(90)
forward(40)
left(90)
forward(40)

FR wrote:

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

У меня большая часть программ работают днями (серверный софт). Даже
клиентские программы на моем компьютере иногда неделями висят.

> деструктроы вызываются(документация это гарантирует). И вот этот
> пример тоже всегда срабатывает:

Деструкторы не всегда вызываются _сразу_ при выходе из блока. Делаем
такой пример:

class Test:
    def crashIt(self):
       cyclic=self
       db_connection=connect_to_database(...)
tst=Test()

Все! Теперь соединение к БД будет существовать до запуска детектора
циклов (или сборщика мусора), а за это время вполне могут быть
израсходованы все соединения к БД.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

FR wrote:

> C>_Уже_ поменяли в Jython и IronPython (или как его там зовут). Когда
> C>выйдет Parrot, то поменяют и в обычном Питоне.
> Как я уже писал разработчики Jython лентяи

Они не лентяи, просто недетерминированая финализация — почти что
фундаментальное свойство GC.

> уже с 2001 года не могут новую версию сделать. А IronPython еще
> глубокая альфа.

В новых версиях поведение деструкторов вряд ли поменяется, так как
подсчет ссылок (который сейчас используется в CPython'е) — чрезвычайно
тормозной.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, FR, Вы писали:

FR>Здравствуйте, Трурль, Вы писали:

Т>>Здравствуйте, eugals, Вы писали:

E>>>А теперь то же самое с использованием возможностей питона 2.4:
E>>>

E>>>file("out.txt", "w").writelines(sorted(file("test.txt")))
E>>>

Т>>Чисто для прикола:
Т>>

Т>>"out.txt" 0: t[<t: 0: "text.txt"]
Т>>

FR>Ruby?

Не похож.

Здравствуйте, FR, Вы писали:
FR>from turtle import *
Боюсь, что как только заходит речь об import, то практически любой язык общего назначения будет выглядеть одинаково. Разница только в количестве и разнообразии доступных библиотек.
Мериться составом RTL в этом смысле не очень показательно. Показательно сравнивать затраты на подготовку этих библиотек; или сравнивать состав стандартной поставки с точки зрения некоторой группы задач. Ну, вот скажем, Cw на порядок лаконичнее C# при работе с XML и SQL. А вот задача копирования группы файлов элегантнее решается на языке командной строки DOS (не говоря уже о более продвинутых шеллах).
Кстати, раз уж речь зашла:

sort < out.txt > out2.txt

Здравствуйте, Cyberax, Вы писали:

C>FR wrote:

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

C>У меня большая часть программ работают днями (серверный софт). Даже
C>клиентские программы на моем компьютере иногда неделями висят.

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

>> деструктроы вызываются(документация это гарантирует). И вот этот
>> пример тоже всегда срабатывает:

C>Деструкторы не всегда вызываются _сразу_ при выходе из блока. Делаем

В том примере необходимости вызова деструкторов сразу после выхода из блока
(вернее строки) нет.

C>такой пример:
C>

C>class Test:
C>    def crashIt(self):
C>       cyclic=self
C>       db_connection=connect_to_database(...)
C>tst=Test()
C>

C>Все! Теперь соединение к БД будет существовать до запуска детектора
C>циклов (или сборщика мусора), а за это время вполне могут быть
C>израсходованы все соединения к БД.

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

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

Здравствуйте, Cyberax, Вы писали:

C>FR wrote:

>> C>_Уже_ поменяли в Jython и IronPython (или как его там зовут). Когда
>> C>выйдет Parrot, то поменяют и в обычном Питоне.
>> Как я уже писал разработчики Jython лентяи

C>Они не лентяи, просто недетерминированая финализация — почти что
C>фундаментальное свойство GC.

Угу, но они вполне могли сделать неявный using.

>> уже с 2001 года не могут новую версию сделать. А IronPython еще
>> глубокая альфа.

C>В новых версиях поведение деструкторов вряд ли поменяется, так как
C>подсчет ссылок (который сейчас используется в CPython'е) — чрезвычайно
C>тормозной.

Наверно из-за этого Jython с настоящим GC работает медленее чем CPython.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, FR, Вы писали:
FR>>from turtle import *
S>Боюсь, что как только заходит речь об import, то практически любой язык общего назначения будет выглядеть одинаково. Разница только в количестве и разнообразии доступных библиотек.

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

S>Мериться составом RTL в этом смысле не очень показательно. Показательно сравнивать затраты на подготовку этих библиотек; или сравнивать состав стандартной поставки с точки зрения некоторой группы задач. Ну, вот скажем, Cw на порядок лаконичнее C# при работе с XML и SQL. А вот задача копирования группы файлов элегантнее решается на языке командной строки DOS (не говоря уже о более продвинутых шеллах).

Про затраты как раз и идет разговор, что на питоне писать проще.

S>Кстати, раз уж речь зашла:
S>

S>sort < out.txt > out2.txt
S>

S>)

так чем же плох питон если на нем эта задача решается практически так же просто, и просто решаются задачи которые на любом шеле неразрешимы.

Здравствуйте, FR, Вы писали:

FR>А читать потом этот код тоже автокомплит будет?
Учтитывая особенности человеческого чтения это не есть проблема.
К томуже статически типизированые языки позволяют создавать утилиты для рефакторинга. Нука покажи мне аналог ReSharper'а для питона...

FR>Конечно правда, вот в питоне шаблонами и не пахнет а обобщеный код пишется без проблем.
Знаешь я лучше буду пользоваться шаблоными чем терпеть выходки питона. То он переменную сам объявит то...
FR>А для решения проблем с нетипизированностью есть специальные утилиты проверяющие корректность кода, например тот же PyChecker.
Вот еще ползоваться какимито левыми утилитами если можно взять нормальный язык.

FR>Скорее с потоками, а файлы так на закуску.
А смысл?

FR>Угу чтобы пару строк кода написать будешь переключатся на другой язык.
Если мне понадобится что-то хитровывернутое то я какнибудь обойдусь.

FR>Так библиотеки еще и написать надо.
Не надо. Ибо толку от них всеравно не будет.

FR>Ну это же не компилируемый кусок, как я понял есть список игровых объектов надо пройтись по нему и взорвать те которые на нужном расстоянии от бомбы, так этот код слово в слово можно переписать на питоне (yeld там тоже есть). Ты лучше опиши задачу и дай реализацию на шарпе, а так не знай откуда вырваные куски не интересно.
Дело в том что все скрипты в играх будут выглядеть примерно так как я показал. Те возможностей C#2 для них выше крыши.

Здравствуйте, Gaperton, Вы писали:

G>Да правда чтоли? VB со своим IDispatch, JScript, PHP, Perl и ваш любимый C# c контейнерами Object-ов — типизированны по самое нехочу?
С++, C#2...

Здравствуйте, Sinclair, Вы писали:

S>Здесь можно было чуть сэкономить. Функция преобразования стрима в строковый енумератор уже есть. Насколько я помню, есть также генерик делегат Transform.
S>Соответственно, можно написать простейший метод
Я библиотеку .NET2 еще не изучал. Времени нет.

Здравствуйте, FR, Вы писали:

FR>Не надо по деревьям лазить, достаточно брать любую небольшую утилитку активно работающую с текстовыми файлами, объем кода будет сильно меньше чем на плюсах или шарпе, близко к объему на перле, но в отличии от перла не write-only а вполне читабельный код.
Любимый прием местных философов подменить тему разговора... Мы же вроде о скриптах в играх говорили, а не об обработки текстовых файлов.

Здравствуйте, FR, Вы писали:
FR>Так питон тем и удобен что очень много упаковано в его стандартные библиотеки. Там же тот же принцип что и в плюсах все что возможно вынести в библиотеку выносится.
Гм. Это "много" — настолько относительная штука, господа...
Тем, кто пишет обработку текста, нужна среда со встроенными средствами на эту тему. Кстати, тоже занятная штука. Кодировки, детектирование, аппер/ловер, паттерн матчинг ака регекспы...
Тем, кто пишет математику, библиотека без комплексных чисел и матричной алгебры покажется децким лепетом.
Ну и так далее.
Я в этом плане человек темный. Насколько мне известно, наиболее полным покрытием предметной области обладает Java. Там вообще сложно придумать область, для которой нет готового стандарта, его референс имплементации, а также пары из коммерческого и некоммерческого решений.

FR>Про затраты как раз и идет разговор, что на питоне писать проще.
Смотря что писать.
Понимаешь, если у меня стоит задача сортировать список строк, то можно написать язык из одной команды. Которую для упрощения обозначить символом "пробел" — по нему промахнуться труднее. И на олимпиаде по сортировке списка строк рвать конкурентов в разы. А когда мы говорим о general purpose языке программирования, на первый план выезжают способы повторного использования и их стоимость, в терминах как разработки (производительность), так и эксплуатации (быстродействие). Я пока не убедился в значительном преимуществе питона в этом плане над альтернативными языками.

Здравствуйте, FR, Вы писали:

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

Здравствуйте, WolfHound, Вы писали:
WH>Я библиотеку .NET2 еще не изучал. Времени нет.
я тоже.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, FR, Вы писали:

FR>>Я понимаю конечно что иногда очень сильно тянет кого нибудь поучить, сам
FR>>этим изредка страдаю, но извини не стоит раздувать из мухи слона, и превращать
FR>>вполне корректный пример в повод демонстрировать конец света.
WH>Ничего никуда не превращается, а просто демонстрируется порочность данной практики.

Имхо, зря тут на FR наехали по поводу кода

arr = open("test.txt").readlines()
arr.sort()

out = open("out.txt", "w")
for line in arr:
    print >> out, line,

Ведь насколько я понимаю, это полностью готовая программа на Python-е. Ее можно отдать Python-у и он ее выполнит. Т.е. это не выдранный откуда-то фрагмент, который нуждается в оборачивание в какой-нибудь import+class+main().

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

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, FR, Вы писали:

FR>>А читать потом этот код тоже автокомплит будет?
WH>Учтитывая особенности человеческого чтения это не есть проблема.

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

WH>К томуже статически типизированые языки позволяют создавать утилиты для рефакторинга. Нука покажи мне аналог ReSharper'а для питона...

Лично я не использую подобные утилиты, и не знаю есть ли подобное для питона, но не вижу проблем в ее написании для питона(кроме большого объема работы).

FR>>Конечно правда, вот в питоне шаблонами и не пахнет а обобщеный код пишется без проблем.
WH>Знаешь я лучше буду пользоваться шаблоными чем терпеть выходки питона. То он переменную сам объявит то...

Сам не объявит

FR>>А для решения проблем с нетипизированностью есть специальные утилиты проверяющие корректность кода, например тот же PyChecker.
WH>Вот еще ползоваться какимито левыми утилитами если можно взять нормальный язык.

Так ты же пользуешся левой утилитой ReSharper?
Раньше и для си был lint очень похож на PyCheker.

FR>>Скорее с потоками, а файлы так на закуску.
WH>А смысл?

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

FR>>Угу чтобы пару строк кода написать будешь переключатся на другой язык.
WH>Если мне понадобится что-то хитровывернутое то я какнибудь обойдусь.

понятно

FR>>Так библиотеки еще и написать надо.
WH>Не надо. Ибо толку от них всеравно не будет.

угу если чего нет в шарпе то это ниому не нужно

FR>>Ну это же не компилируемый кусок, как я понял есть список игровых объектов надо пройтись по нему и взорвать те которые на нужном расстоянии от бомбы, так этот код слово в слово можно переписать на питоне (yeld там тоже есть). Ты лучше опиши задачу и дай реализацию на шарпе, а так не знай откуда вырваные куски не интересно.
WH>Дело в том что все скрипты в играх будут выглядеть примерно так как я показал. Те возможностей C#2 для них выше крыши.

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

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, FR, Вы писали:

FR>>Не надо по деревьям лазить, достаточно брать любую небольшую утилитку активно работающую с текстовыми файлами, объем кода будет сильно меньше чем на плюсах или шарпе, близко к объему на перле, но в отличии от перла не write-only а вполне читабельный код.
WH>Любимый прием местных философов подменить тему разговора... Мы же вроде о скриптах в играх говорили, а не об обработки текстовых файлов.

Не я виноват что тему переместили и обозвали "Python vs C#".

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, FR, Вы писали:
FR>>Так питон тем и удобен что очень много упаковано в его стандартные библиотеки. Там же тот же принцип что и в плюсах все что возможно вынести в библиотеку выносится.
S>Гм. Это "много" — настолько относительная штука, господа...
S>Тем, кто пишет обработку текста, нужна среда со встроенными средствами на эту тему. Кстати, тоже занятная штука. Кодировки, детектирование, аппер/ловер, паттерн матчинг ака регекспы...

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

S>Тем, кто пишет математику, библиотека без комплексных чисел и матричной алгебры покажется децким лепетом.
S>Ну и так далее.
S>Я в этом плане человек темный. Насколько мне известно, наиболее полным покрытием предметной области обладает Java. Там вообще сложно придумать область, для которой нет готового стандарта, его референс имплементации, а также пары из коммерческого и некоммерческого решений.

может быть

FR>>Про затраты как раз и идет разговор, что на питоне писать проще.
S>Смотря что писать.

это да.

S>Понимаешь, если у меня стоит задача сортировать список строк, то можно написать язык из одной команды. Которую для упрощения обозначить символом "пробел" — по нему промахнуться труднее. И на олимпиаде по сортировке списка строк рвать конкурентов в разы. А когда мы говорим о general purpose языке программирования, на первый план выезжают способы повторного использования и их стоимость, в терминах как разработки (производительность), так и эксплуатации (быстродействие). Я пока не убедился в значительном преимуществе питона в этом плане над альтернативными языками.

Пока ты будешь писать свой пробельный язык я давно уже решу эту же задачу одной строкой кода в питоне. Разработку питон сильно ускоряет.