On 08/03/14 15:30, Maciej Fijalkowski wrote:
On Sat, Mar 8, 2014 at 5:14 PM, Victor Stinner victor.stin...@gmail.com wrote:
2014-03-08 14:33 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Ok, it's actually quite trivial. The whole chain is kept alive by the
fut global variable. If you arrange
2014-03-08 16:30 GMT+01:00 Maciej Fijalkowski fij...@gmail.com:
How about fixing cyclic gc to deal with __del__ instead? That sounds
like an awful change to the semantics.
Hum? That's the purpose of the PEP 442 which is implemented in Python 3.4.
As I wrote, it's not enough to fix all issues.
On Mon, Mar 10, 2014 at 12:10 PM, Victor Stinner
victor.stin...@gmail.com wrote:
2014-03-08 16:30 GMT+01:00 Maciej Fijalkowski fij...@gmail.com:
How about fixing cyclic gc to deal with __del__ instead? That sounds
like an awful change to the semantics.
Hum? That's the purpose of the PEP 442
On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner
victor.stin...@gmail.com wrote:
2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski fij...@gmail.com:
It was agreed long time ago that the immediate finalization is an
implementation specific detail and it's not guaranteed. You should not
rely on
On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski fij...@gmail.comwrote:
On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner
victor.stin...@gmail.com wrote:
2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski fij...@gmail.com:
It was agreed long time ago that the immediate finalization is an
On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski fij...@gmail.com
wrote:
On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner
victor.stin...@gmail.com wrote:
2014-03-10 13:11 GMT+01:00 Maciej Fijalkowski
On Mon, Mar 10, 2014 at 10:39 AM, Maciej Fijalkowski fij...@gmail.comwrote:
On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum gu...@python.org
wrote:
On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski fij...@gmail.com
wrote:
On Mon, Mar 10, 2014 at 3:23 PM, Victor Stinner
On Mon, Mar 10, 2014 at 7:49 PM, Guido van Rossum gu...@python.org wrote:
On Mon, Mar 10, 2014 at 10:39 AM, Maciej Fijalkowski fij...@gmail.com
wrote:
On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum gu...@python.org
wrote:
On Mon, Mar 10, 2014 at 10:30 AM, Maciej Fijalkowski
On Mon, Mar 10, 2014 at 10:56 AM, Maciej Fijalkowski fij...@gmail.comwrote:
On Mon, Mar 10, 2014 at 7:49 PM, Guido van Rossum gu...@python.org
wrote:
On Mon, Mar 10, 2014 at 10:39 AM, Maciej Fijalkowski fij...@gmail.com
wrote:
On Mon, Mar 10, 2014 at 7:35 PM, Guido van Rossum
On Mon Mar 10 18:56:17 CET 2014 (and earlier quotes), Maciej Fijalkowski wrote:
Maciej: You should not rely on __del__s being called timely one way or
Maciej: another. Why would you require this for the program to work
Maciej: correctly in the particular example of __traceback__?
To the extent
On Mon, 10 Mar 2014 16:08:52 -0700 (PDT)
Jim J. Jewett jimjjew...@gmail.com wrote:
It may also be more common to have multiple __del__ methods in the
same cycle, if cycles are created by a framework. So the problems
aren't new, but they may have become considerably more painful.
Multiple
2014-03-08 1:14 GMT+01:00 Jim Jewett jimjjew...@gmail.com:
Could you clarify what the problem actually is?
Please see:
http://bugs.python.org/file33238/never_deleted.py
I would not expect it to be cleared at least until go runs ... and reading
the ticket, it sounds like it is cleared then.
On Sat, Mar 8, 2014 at 9:06 PM, Victor Stinner victor.stin...@gmail.com wrote:
And MyObject is not destroyed which is an obvious memory leak, beause
there is no more explicit reference to it.
And it doesn't seem to be getting put into gc.garbage, either, which
is probably worth mentioning. You
On Sat, 8 Mar 2014 11:06:54 +0100
Victor Stinner victor.stin...@gmail.com wrote:
Attached script: never_deleted2.py, it's almost the same but it
explains better the problem. The script creates MyObject and Future
objects which are never deleted. Calling gc.collect() does *not* break
the
2014-03-08 12:45 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Attached script: never_deleted2.py, it's almost the same but it
explains better the problem. The script creates MyObject and Future
objects which are never deleted. Calling gc.collect() does *not* break
the reference cycle (between
On 8 March 2014 23:01, Victor Stinner victor.stin...@gmail.com wrote:
2014-03-08 12:45 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Attached script: never_deleted2.py, it's almost the same but it
explains better the problem. The script creates MyObject and Future
objects which are never
On Sat, 8 Mar 2014 23:16:07 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 8 March 2014 23:01, Victor Stinner victor.stin...@gmail.com wrote:
2014-03-08 12:45 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Attached script: never_deleted2.py, it's almost the same but it
explains better the
2014-03-08 14:33 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Ok, it's actually quite trivial. The whole chain is kept alive by the
fut global variable. If you arrange for it to be disposed of:
fut = asyncio.Future()
asyncio.Task(func(fut))
del fut
[etc.]
then the problem
On Sat, Mar 8, 2014 at 5:14 PM, Victor Stinner victor.stin...@gmail.com wrote:
2014-03-08 14:33 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Ok, it's actually quite trivial. The whole chain is kept alive by the
fut global variable. If you arrange for it to be disposed of:
fut =
On Sat, 8 Mar 2014 16:14:23 +0100
Victor Stinner victor.stin...@gmail.com wrote:
2014-03-08 14:33 GMT+01:00 Antoine Pitrou solip...@pitrou.net:
Ok, it's actually quite trivial. The whole chain is kept alive by the
fut global variable. If you arrange for it to be disposed of:
fut =
On 03/07/2014 01:20 PM, Jim J. Jewett wrote:
(E) Exceptions are not released even during cyclic gc, because
of ambiguity over which __del__ to run first.
+ This may be like case B or case E
Um, this is case E. ;)
--
~Ethan~
___
Python-Dev
On 3/7/2014 1:25 PM, Ethan Furman wrote:
On 03/07/2014 01:20 PM, Jim J. Jewett wrote:
(E) Exceptions are not released even during cyclic gc, because
of ambiguity over which __del__ to run first.
+ This may be like case B or case E
Um, this is case E. ;)
Yeah, quite a bit like case E :)
Could you clarify what the problem actually is?
Please see:
http://bugs.python.org/file33238/never_deleted.py
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
23 matches
Mail list logo
