Jeremy Hylton wrote: > Can you expand on why you think this approach is fundamentally flawed?
I would expect that you allocate in the process memory that needs to outlive the arena, e.g. python strings. The fundamental problem is that the arena deallocation cannot know whether such memory exists, and what to do with it. So two things may happen: - you mistakenly allocate long-lived memory from the arena, and then discard it when you discard the arena. This gives you dangling pointer. The problem here is that at the allocation point, you may not know (yet) either whether this is going to survive the arena or not. - you allocate memory outside of the arena to survive it, and then something goes wrong, and you deallocate the arena. Yet, the outside memory remains garbage. IOW, there would be no problem if you were *completely* done when you throw away the arena. This is not the case, though: eventually you end up with byte code that need to persist. > Sure does. It seems like the code generation from the AST description > also makes this kind of experimentation easier. Indeed. I wish there was a way to generate ast.c from a transformation description as well. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
