LINUX.ORG.RU
ФорумTalks

[жж] читаю доку по пайтону

 


0

0

...и офигеваю.

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

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

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

★★★★★

Ответ на: комментарий от sign

> сборка мусора с подсчетом ссылок (циклы не собирает)

Ты давно из криокамеры? Сборщик мусора собирает циклы, начиная с 2.0

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>> сборка мусора с подсчетом ссылок (циклы не собирает)

Ты давно из криокамеры? Сборщик мусора собирает циклы, начиная с 2.0

Ну да видимо, давно. Сейчас почитал, вроде бы python начал собирать циклы из объектов, которые без finalizerов. В общем мне непонятно, почему нельзя сразу использовать сборщик мусора - зачем надо считать, считать, ссылки. Потом зарегистрировать все контейнерные объекты в списках объектов. А затем искать циклы. Затем найденные циклы освобождать (или добавлять в список неосвобожденного мусора).

Неужели это быстрее, чем просто реализовать сборку мусора?

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

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

sign
()
Ответ на: комментарий от sign

> Сейчас почитал, вроде бы python начал собирать циклы из объектов, которые без finalizerов.

...причем едвали не 10 лет назад

Неужели это быстрее, чем просто реализовать сборку мусора?

Мне интересно - все люди, которым не хватает скорости Питона, с ним _не_ работают, или есть такие, кому «медленность» Питона мешает в реальной работе?

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

Вот прям-таки «нельзя»? Где такие рекомендации?

Если память закончилась - сборка мусора не поможет и т.д.

Похоже на правду, но хотелось бы знать контекст.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

сборка мусора с подсчетом ссылок (циклы не собирает)

Ты давно из криокамеры? Сборщик мусора собирает циклы, начиная с 2.0

Также радует вот это

http://bugs.python.org/issue4794

Python's garbage collector holds GIL during collection and doesn't provide any method of interruption or concurrency with other Python threads within a single Python VM. This can be a problem for realtime applications. The worst-case performance of the garbage collector takes linear time (выделение мое) with respect to the number of Python objects that could potentially be involved in a garbage cycle.

Особенно радует вот эта рекомендация

Hard real-time applications written in Python should not rely on the cyclic garbage collector. They should call gc.disable at startup, and completely rely on reference counting for releasing memory. Doing so might require rewrites to the application, explicitly breaking cycles so that reference counting can release them.

Костыли, такие костыли. ;)

sign
()
Ответ на: комментарий от sign

> Hard real-time applications written in Python should not rely on the cyclic garbage collector. They should call gc.disable at startup, and completely rely on reference counting for releasing memory.

Костыли, такие костыли. ;)

Бгг. Покажи мне 2 вещи: 1) hard realtime приложение на Питоне; 2) любую систему, которая поддерживает сборку мусора в hard realtime. Потом поговорим о костылях...

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> 1) hard realtime приложение на Питоне;

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

В любом случае спасибо за замечание про сборку циклов в питоне. Узнал для себя много нового.

sign
()
Ответ на: комментарий от sign

>> 1) hard realtime приложение на Питоне;

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

Ты смотрел аттачмент к этому багу? Приведенный код, мягко говоря, очень странен для приложения реального времени..

К.О. хотел привести определение «жесткого» реального времени, но поленился %)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Ты смотрел аттачмент к этому багу?

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

Также я понял Вашу точку зрения, что с циклическими ссылками у питона проблем нет. Моя точка зрения прямо противположна - я считаю, что с циклическими ссылками проблемы у питона имеются.

sign
()
Ответ на: комментарий от sign

>> Ты смотрел аттачмент к этому багу?

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

А я присмотрелся второй раз - там же тупо утечка памяти %) Предлагать это в качестве теста GC - ну просто бугага.

Моя точка зрения прямо противположна - я считаю, что с циклическими ссылками проблемы у питона имеются.

Я довольно много программирую на Питоне, и ни разу с ними не сталкивался.

tailgunner ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.