Лол, не надо

Марка это не убедит, а Зарт лишний раз нервы потратит

Он знает об этом обсуждении

Мы уже эту тему обсасывали

реализации питона есть не только на сях, но и на шарпе и жабе как минимум, бтв

и на питоне 8)

Там чуть выше

Про сокеты

а на питоне питона слабо ?

а на питоне питона слабо ?

Пфф На питоне с++ изи

В том чатике обсуждают Python... внезапно

@zartsoft а чем тебе del() не деструктор?

Да там и обсуждали петон

>>> class a: ... def __del__(self): ... print('del') ... >>> b = a() >>> c = b >>> del b >>> del c del

del не дестркутор, __del__ деструктор

Да там и обсуждали петон

Сколько помню - там обсуждали все подряд, но только не Python

Нет.

Но бывают моменты, когда все молчат - и чатик нужно взбодрить

del не дестркутор, __del__ деструктор

он впринципе тогда и обсуждался

с ошибочкой написал

Но бывают моменты, когда все молчат - и чатик нужно взбодрить

Своей тупостью

Своей тупостью

Да ты что? Писал под рав сокеты хоть что-то?

видимо из за утечки памяти деструктор иногда не может удалить два объекта, на бэкендах это критично

Да ты что? Писал под рав сокеты хоть что-то?

Я писал, мне норм

Да мне то тоже норм, но раздражают ебланы, которые рассказывают про высокоуровневый петон

систему приходится перезагружать чтоб аварийно не завершиться=)

sock = socket.socket() sock.bind(('127.0.0.1', self.port)) sock.listen(16) while True: conn, addr = sock.accept() data = conn.recv(65536).decode('utf-8')

Просто слушать несложно

Да ты что? Писал под рав сокеты хоть что-то?

Я? - Нет. Ты без пруфов начал говорить мол говно они. Скинув при этом в стринге выхлоп, аки это мусор на самом деле. В utf-8 выхлоп, ага. Сверхразум. А потом что-то загонял нам про https протокол и байтики, попутно обсирая всех

На eth подцепи

Когда у тебя спрашивали, а что к чему, зачем ты говоришь про https, совсем упоролся?

Ты начал ебашить маты и несвязную хуету, а потом слился

Это когда меня какой-то хуй на тупом зобанил?

@zartsoft а чем тебе del() не деструктор?

финализатор. в отличие от деструктора не имеет отношения к операции освобождения памяти напрямую

В джаве или шарпе есть деструкторы?

в жабе похоже нет

Вообще в языках с автоматической сборкой мусора могут быть деструкторы?

финализатор. в отличие от деструктора не имеет отношения к операции освобождения памяти напрямую

Но в конечном итоге все успешно освобождается?

мммм

Просто питон высокоуровневый, не думаю что надо вот так прям брать и чистить память Он наверное все линки на себя чистит?

__del__ в цпитоне вызывается в момент, когда рефкаунт объекта достигает нуля цимес в том, что в этот момент можно создать новую ссылку на объект, увеличив счетчик и не дав объекту помереть

в багтрекере был шикарный баг на эту тему

А если вручную вызывать?

а толку

"когда рефкаунт объекта достигает нуля" Я думал это автоматическое удаление когда уже не нужен объект

http://bugs.python.org/issue10794 ыыы

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

нихуя ты вручную не можешь

только удалять ссылки

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

ну

Из си можно

пока на него ссылки есть - объект жив

Из си можно

и словить некислые глюки

пока на него ссылки есть - объект жив

То есть a = A() A() A().__del__() #Не удалит?! A()

del a

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

Да я попутал аперкейсы

вызов __del__ вручную бессмысленен

Так че

?

ничего ты не попутал

просто ерунду нарисовал

a.__del__()

Почему нет?

>>> class c: ... def __del__(self): ... print('del') ... >>> a = c() >>> a.__del__() del >>> a.__del__() del >>> a.__del__() del >>> a <__main__.c object at 0x7f2dc6ef5358>

Лел

ERROR: S client not available

лол

а если def __del__(self): self.__del__()

эм

Из си можно

>>> ctypes.pythonapi.PyMem_Free <_FuncPtr object at 0x02DFC8A0> только я тебе этого не говорил

RecursionError: maximum recursion depth exceeded

вот тоже

думаю

Я не шарю кароче

__del__ НЕ УДАЛЯЕТ оно вызывается в момент удаления оно не причина, а следствие

А del(obj)? Не аналог?

>>> class a: ... def __del__(self): ... print('del') ... >>> b = a() >>> c = b >>> del b >>> del c del

a = A() что происходит в этом коде? питон создает экземпляр класса - на уровне Си это создается PyObject на хипе, рефкаунт равен 0 a = - тут питон создает в локальном фрейме имя "a", заносит в него указатель на память где находится наш PyObject, а рефкаунт инкрементирует

в итоге мы имеем переменную а, ссылающуюся на объект с рефкаунтом равным 1

Это ясно

А инструкция?

Инит

print(a) - в момент вызова, мы создаем новый фрейм, у которого есть переменные-аргументы. вызов присваивает им значения, и увеличивает рефкаунт снова

т.е. в момент вызова функции - у а счетчик будет равен 2

после того как функция вернется, фрейм освободится, со всеми именами/переменными внутри и при освобождении будет уменьшен счетчик

т.е. после того как принт отработает - у объекта будет 1

делаем теперь del a

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

на этом этапе цпитон сразу же вызывает __del__ метод объекта

>>> class a: ... def __del__(self): ... print('del') ... >>> b = a() >>> c = b >>> del b >>> del c del

что и произошло вот тут

если метод не увеличит рефкаунт, то после его отработки произойдет PyMem_Free(obj) в сях

там чуток сложнее, но смысл такой, что память вернется в хип

как видно, прямого PyMem_Free аналога у нас нет мы можем только опосредованно заставить объект уничтожиться, удалив на него все связи

но например можно сделать такое... class A(object): pass a = A() a.selfref = a

del a # упс... но внутри а есть ссылка на сам а, поэтому рефкаунт всегда будет 1

это называется циклом, поэтому питон изредка прогоняет сборку мусора, которая ищет подобные вещи

после чего принудительно разрывает ссылки и чистит объекты, вызывая их __del__

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