Re: [Python-Dev] PEP-xxx: Unification of for statement and list-comp syntax
> I saw them. Your brain must be wired very differently > to mine, because I find loops with a continue in them > harder to follow than ones without -- exactly the > opposite of what you seem to prefer. Delurking for no particular reason: For what it's worth, I also favor the continue syntax Heiko compared his code against. Without it, you have to scroll to the end of the loop to know whether there is an else clause; it also allows you to have multiple conditions expressed up-front without a lot of indentation. In general, I favor the idea that the main flow of computation should have the least indentation. I also am +1 on this PEP, even if it is doomed, as I've often longed to use list- comprehension like syntax in a for loop; to me it is mentally taxing to remember which syntax is supported where. Just thought I'd throw Heiko some support. :) Niko ___ 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
[Python-Dev] Python Benchmarks
Hello, After reading through recent Python mail regarding dictionaries and exceptions, I wondered, what is the current state of the art in Python benchmarks? I've tried before to find a definite set of Python benchmarks but failed. There doesn't seem to be an up to date reference, though if there is one and I didn't find it I would be very happy to be proven wrong. In any case, I would appreciate advice from the experts regarding what's available and what it tests. thank you, Niko Matsakis ___ 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
Re: [Python-Dev] Bare except clauses in PEP 348
> As for the rest, I'm not as sure and it would be helpful to get > thoughts > from others on this one. My sense is that blocking the clause from > appearing in the middle is treating the symptom and not the disease. +1 It would be better to prohibit bare except entirely (well, presumably at some point in the future with appropriate warnings at the moment) than change its semantics. I agree that its intuitive meaning is "if anything is thrown", not, "if a non-programmer-error exception is thrown," but I'm not sure if that's even important. The point is that it has existing well defined semantics; changing them just seems unnecessary to the aims of the rewrite and confusing to existing Python programmers. I've written plenty of code with bare excepts and they all intended to catch *any* exception, usually in a user interface where I wanted to return to the main loop on programmer error not abort the entire program. I don't relish the thought of going back and changing existing code, and I imagine there are few who do. My 2 cents, Niko ___ 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
Re: [Python-Dev] Bare except clauses in PEP 348
> > txn = new_transaction() > try: > txn.begin() > rtn = do_work() > finally: > if exception_occurred(): > txn.abort() > else: > txn.commit() > return rtn > Couldn't you just do: txn = new_transaction () try: complete = 0 txn.begin () rtn = do_work () complete = 1 finally: if not complete: txn.abort () else: txn.commit () and then not need new builtins or anything fancy? Niko ___ 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
Re: [Python-Dev] Memory management in the AST parser & compiler
> As Neal pointed out, it's tricky to write code for the AST parser > and compiler > without accidentally letting memory leak when the parser or > compiler runs into > a problem and has to bail out on whatever it was doing. Thomas's > patch got to > v5 (based on Neal's review comments) with memory leaks still in it, > my review > got rid of some of them, and we think Neal's last review of v6 of > the patch > got rid of the last of them. Another lurker's 2 cents: My experience with compilers in particular is that an arena is the way to go for memory management. I haven't looked at the AST code, but this can take a variety of forms: anything from linked lists of pointers to free from something which allocates memory in large blocks and parcels them out. The goal is just to be able to free the memory en-masse whatever happens and not have to track individual pointers. Generally, compilers have memory allocations which operate in phases and so are very amenable to arenas. You might have one memory pool for long lived representation, one that is freed and recreated between passes, etc. If you need to keep the AST around long term, then a mark-sweep garbage collector combined with a linked list might even be a good idea. Obviously, the whole thing is a tradeoff of peak memory size (which goes up) against correctness (which is basically ensured, and at least easily auditable). Niko ___ 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
Re: [Python-Dev] Memory management in the AST parser & compiler
> Boy am I wanting RAII from C++ for automatic freeing when scope is > left. Maybe we need to come up with a similar thing, like all memory > that should be freed once a scope is left must use some special struct > that stores references to all created memory locally and then a free > call must be made at all exit points in the function using the special > struct. Otherwise the pointer is stored in the arena and handled > en-mass later. That made sense. I think I'd be opposed to what you describe here just because I think anything which *requires* that cleanup code be placed on every function is error prone. Depending on how much you care about peak memory usage, you do not necessarily need to worry about freeing pointers as you go. If you can avoid thinking about it, it makes things much simpler. If you are concerned with peak memory usage, it gets more complicated, and you will begin to have greater possibility of user error. The problem is that dynamically allocated memory often outlives the stack frame in which it was created. There are several possibilities: - If you use ref-counted memory, you can add to the ref count of the memory which outlives the stack frame; the problem is knowing when to drop it down again. I think the easiest is to have two lists: one for memory which will go away quickly, and another for more permanent memory. The more permanent memory list goes away at the end of the transform and is hopefully rarely used. - Another idea is to have trees of arenas: the idea is that when an arena is created, it is assigned a parent. When an arena is freed, an arenas in its subtree are also freed. This way you can have one master arena for exception handling, but if there is some sub-region where allocations can be grouped together, you create a sub-arena and free it when that region is complete. Note that if you forget to free a sub-arena, it will eventually be freed. There is no one-size-fits-all solution. The right one depends on how memory is used; but I think all of them are much simpler and less error prone than tracking individual pointers. I'd actually be happy to hack on the AST code and try to clean up the memory usage, assuming that the 2.6 release is far enough out that I will have time to squeeze it in among the other things I am doing. Niko ___ 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
