Re: [Python-Dev] PEP 343 - next steps
I can't make time for this right now, but the more I think about it, the more I believe the worry about asynchronous exceptions is mostly irrational. Despite your proof that it *can* be implemented I really don't want to see anything like that implemented -- I doubt that you've covered all the cases and I don't like inserting new opcodes to handle a case that most programs don't care about. Declaring something atomic that could span an arbitrary amount of Python code execution (including calls) just doesn't seem right. Disregarding asynchronous exceptions, you can already use with-statements for your beloved RAII pattern, right? I'm still skeptical how important it is in Python -- its seems something invented very specifically for C++'s guarantee of local destructor execution, and I don't expect to see all that many applications for it in Python. The with-statement is about the reduction of boiler-plate code involving try-finally, and that is typically not used for resource release (unless you count locks, where RAII is inappropriate -- at least in Python). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] [ANN] Have fun programming with your kids
Hi If you are a parent, an educator or a programmer having kids this is for you! After 4 years of work, my new book Squeak: Learn programming with Robots will be out soon. http://smallwiki.unibe.ch/botsinc/ http://www.amazon.com/exec/obidos/tg/detail/-/1590594916/ qid=1117218524/sr=1-1/ref=sr_1_1/002-5642974-5143261?v=glances=books With Bots Inc you will learn how to program robots in an interactive environment. Bots Inc proposes three teaching approaches: direct command of robots, scripting robots and programming robots. The book contains 24 chapters going step by step over topics with a lot of examples. Bots Inc is fun but it is not a toy, it teaches you 100% real programming. Bots Inc is built on top of the rich open-source multimedia Squeak environment that you can also discover. My goal is to explain key elementary programming concepts (such as loops, abstraction, composition, and conditionals) to novices of all ages. I believe that learning by experimenting and solving problems with fun is central to human knowledge acquisition. Therefore, I have presented programming concepts through simple but not trivial problems such as drawing golden rectangles or simulating animal behavior. The ideal reader I have in mind is an individual who wants to have fun programming. This person may be a teenager or an adult, a schoolteacher, or somebody teaching programming to children in some other organization. Such an individual does not have to be fluent in programming in any language. As a father of two young boys I also wrote this book for all the parents that want to have fun programming with their kids in a powerful interactive environment. Programming in Squeak is an interactive, fun but deep experience. The present book teaches elementary programming aspect, the following book will introduce a new fun environment and teach object-oriented programming. Testimonies I am using the version of the book on your web site to teach my oldest daughter Becca some programming. She absolutely loves it. We are doing the Bot graphics right. My other kids are showing interest as well. My Fall semester schedule leaves me with almost no time free but in the Spring I hope to bring Squeak and your book to our elementary school's gifted program. C. David Shaffer I'm using the Bot Lab environment for three years and found it really valuable in teaching computer science concepts for a young audience (and even less young !). The bots commanded through balloon (as in comic strips) is a very nice introduction for young children, and when this aspect is well understood, you can use the Bot Workspace to teach the notion of script, a first step in programming languages. The Micro Browser allows children to add new behavior for their bots, and have fun with their creation. This three-layers tool - Balloon, Micro Workspace, Micro Browser - offers to the teacher a fun way to introduce gently the basis of object-oriented programming concepts. With Bots Inc, learning is playing ! ;-) Samir Saidani - University of Caen - France I recently started a course with 7th-graders (age about 13 years) with Stephane's book --- they love it. They all know about syntactic issues from maths --- in a way they know that an expression in a formal language must be well formed. So they easily grasp the fact such as there must be a colon after the message-name if an argument follows. Of cause they don't really read the error-messages, they just see there must be some error and they remember the simple rules. Don't underestimate Smalltalk --- it's easy understandable because it has a simple and straight-forward design. Klaus Fuller - Germany Have fun... Stef http://www.iam.unibe.ch/~ducasse/ if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth CalvinHobbes ___ 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] PEP 343 - next steps
Nick Coghlan [EMAIL PROTECTED] writes: It also considers the possibility of using with statements in an RAII style by acquiring the resource in __init__ or __new__ rather than __enter__. While you can probably do this (after all, most of the time __new__/__init__ and __enter__ will be called in rapid succession) I really think the RAII meme doesn't apply to Python; you generally want a resource to be acquired for a period of definite extent, and objects in Python have indefinite extent, unlike C++ where automatic variables have definite extent (Common Lisp terminology here). I've gone on at length about this before: http://starship.python.net/crew/mwh/pep310/ Cheers, mwh -- Have you considered downgrading your arrogance to a reasonable level? -- Erik Naggum, comp.lang.lisp, to yet another C++-using troll ___ 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] [ANN] Have fun programming with your kids
Dear Mr. Ducasse, The PyDev mailing list, bidirectionally gatewayed to gmane.comp.python.devel, which you apparently used as the insertion point, is a specialized list for discussion and development of the next Python version and occasionally beyond. Even most posts to comp.lang.python (== gmane.comp.python.general) are off-topic here. Your annoucement of a non-Python application book, which you sent numerous places, appears to be out of the ballpark of relevance here. Your book may be wonderful and I might find it useful were I to buy it, but if everyone imitated you, PyDev would have to be closed in order to function. Please desist, both for this and future projects. PS. Ignorance is no excuse. Internet etiquette specifies that before posting, one read a group (mailing list, forum) enough to learn what it is about. ___ 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] Multiple expression eval in compound if statement?
I'm horsing around with recognizing switch-like if statements like: if x == 1: print 1 elif x == 2: print 2 else: print unknown in the compiler and generating O(1) code. x can be any expression, but must be precisely the same in each elif clause, the comparison operator must be == and the RHS of the test must evaluate to a simple hashable constant (string, float, integer - still working on None, constant tuples may be allowed later). I can currently recognize such constructs and am working on code generation. This would represent a semantic change to the Python runtime, because x would only be evaluated once, whereas in existing usage it can potentially be evaluated many times. If evaluating x has side-effects, code like the above that currently works would break. In reading the language reference manual, it says: It selects exactly one of the suites by evaluating the expressions one by one until one is found to be true (see section 5.10 for the definition of true and false); then that suite is executed (and no other part of the if statement is executed or evaluated). If all expressions are false, the suite of the else clause, if present, is executed. It says nothing about possibly caching values, which is what I'm doing effectively, but it seems pretty clear that each full test expression will be evaluated until one evaluates to true. I can't imagine anyone relying on a side-effect when evaluating x in this context, and if someone did, their code would be truly fragile. Still, any thought as to whether or not such a semantic change to the language might be acceptable? Skip ___ 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] PEP 343 - next steps
Guido van Rossum wrote: So (a) would have my preference. Mine, too. the PEP would have to be amended to state that VAR must be a single variable or a list of variables IN PARENTHESES. +1 -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] PEP 343 - next steps
Guido van Rossum wrote: I can't make time for this right now, but the more I think about it, the more I believe the worry about asynchronous exceptions is mostly irrational. Despite your proof that it *can* be implemented I really don't want to see anything like that implemented -- I doubt that you've covered all the cases and I don't like inserting new opcodes to handle a case that most programs don't care about. Declaring something atomic that could span an arbitrary amount of Python code execution (including calls) just doesn't seem right. As I just added to the Wiki, dropping the issue completely works for me. I'm also far from convinced I'd covered all the corner cases (besides, blocking KeyboardInterrupt for an arbitrary amount of time made me uncomfortable). Disregarding asynchronous exceptions, you can already use with-statements for your beloved RAII pattern, right? I'm still skeptical how important it is in Python -- its seems something invented very specifically for C++'s guarantee of local destructor execution, and I don't expect to see all that many applications for it in Python. You'd mostly convinced me that RAII was rare in Python, but two possible use cases remained - files, and call method X of object Y at the end of the block (e.g. closing() from the PEP). Both of those would require any async guarantee to cover evaluation of EXPR in order to be included in the guarantee. If with statements make no guarantees about async exceptions, then there is no problem (as there is officially no difference between the two styles). If we ever do resurrect the idea, I also realised a far simpler solution would involve moving evaluation of EXPR and the call to __enter__ inside the try/finally block, and having an internal flag to indicate whether or not __exit__ should be called as the block is exited. Far less screwing around with ceval.c, and far easier to get right. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] PEP 343 - next steps
Michael Hudson wrote: While you can probably do this (after all, most of the time __new__/__init__ and __enter__ will be called in rapid succession) I really think the RAII meme doesn't apply to Python; you generally want a resource to be acquired for a period of definite extent, and objects in Python have indefinite extent, unlike C++ where automatic variables have definite extent (Common Lisp terminology here). Using the RAII term was probably a bad idea, as it brings in too many extra connotations (like the converse 'RRID' - 'resource release is destruction'). Anyway, Guido's taking the option of not providing any explicit guarantees at this point, which is probably the most sensible idea. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] Multiple expression eval in compound if statement?
I'm horsing around with recognizing switch-like if statements like: if x == 1: print 1 elif x == 2: print 2 else: print unknown in the compiler and generating O(1) code. x can be any expression, but must be precisely the same in each elif clause, the comparison operator must be == and the RHS of the test must evaluate to a simple hashable constant (string, float, integer - still working on None, constant tuples may be allowed later). I can currently recognize such constructs and am working on code generation. I think it unwise to allow x to be any expression. Besides altering existing semantics, it leads to code redundancy and to a fragile construct (where the slightest alteration of any of the expressions triggers a silent reversion to O(n) behavior). Raymond ___ 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] Wishlist: dowhile
Raymond Hettinger wrote: More than case-statement semantics or PEP343, I wish for a dowhile statement. The most straight-forward way is to put the conditional expression at the beginning of the block with the understanding that a dowhile keyword will evaluate the condition only after the block runs Out-of-order code execution rarely counts as 'straightforward' ;) With PEP 315, a do-while loop would look like: do: body while cond: pass But then, I'm reasonably happy with the 'break out of an infinite loop' approach, so *shrug*. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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] PEP 343 - next steps
[Nick] As I just added to the Wiki, dropping the issue completely works for me. I'm also far from convinced I'd covered all the corner cases (besides, blocking KeyboardInterrupt for an arbitrary amount of time made me uncomfortable). OK. You'd mostly convinced me that RAII was rare in Python, but two possible use cases remained - files, and call method X of object Y at the end of the block (e.g. closing() from the PEP). Both of those would require any async guarantee to cover evaluation of EXPR in order to be included in the guarantee. If with statements make no guarantees about async exceptions, then there is no problem (as there is officially no difference between the two styles). Any exception, async or otherwise, that happens before the 'try' of the translation is reached, does *not* cause __exit__ to be called. I just realized that the assignment to VAR (if present) also has to be represented by one or more opcodes, so a special guarantee that __enter__() called by the same opcode that sets up the try cannot work anyway. Forget I said anything about that. If we ever do resurrect the idea, I also realised a far simpler solution would involve moving evaluation of EXPR and the call to __enter__ inside the try/finally block, and having an internal flag to indicate whether or not __exit__ should be called as the block is exited. Far less screwing around with ceval.c, and far easier to get right. We considered this at some point during the PEP 340/343/346 discussion (in fact I had it this way in an early version of one of the PEPs), and in the end decided against it. I believe the argument was that any failure *before* __enter__() returns can be handled by try/except clauses inside __init__() or __enter__(). Changing to this style later would be a major backward incompatibility because the guarantees made to __exit__() are different. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Multiple expression eval in compound if statement?
On 6/12/05, Skip Montanaro [EMAIL PROTECTED] wrote: I'm horsing around with recognizing switch-like if statements like: if x == 1: print 1 elif x == 2: print 2 else: print unknown in the compiler and generating O(1) code. x can be any expression, but must be precisely the same in each elif clause, the comparison operator must be == and the RHS of the test must evaluate to a simple hashable constant (string, float, integer - still working on None, constant tuples may be allowed later). I can currently recognize such constructs and am working on code generation. Cool! This would represent a semantic change to the Python runtime, because x would only be evaluated once, whereas in existing usage it can potentially be evaluated many times. If evaluating x has side-effects, code like the above that currently works would break. In reading the language reference manual, it says: It selects exactly one of the suites by evaluating the expressions one by one until one is found to be true (see section 5.10 for the definition of true and false); then that suite is executed (and no other part of the if statement is executed or evaluated). If all expressions are false, the suite of the else clause, if present, is executed. It says nothing about possibly caching values, which is what I'm doing effectively, but it seems pretty clear that each full test expression will be evaluated until one evaluates to true. I can't imagine anyone relying on a side-effect when evaluating x in this context, and if someone did, their code would be truly fragile. Still, any thought as to whether or not such a semantic change to the language might be acceptable? I think it would be wiser if you only did this when x is a simple local variable. For locals, we *know* that no side effect of any expression can change the value. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Wishlist: dowhile
On 6/12/05, Nick Coghlan [EMAIL PROTECTED] wrote: Raymond Hettinger wrote: More than case-statement semantics or PEP343, I wish for a dowhile statement. The most straight-forward way is to put the conditional expression at the beginning of the block with the understanding that a dowhile keyword will evaluate the condition only after the block runs Out-of-order code execution rarely counts as 'straightforward' ;) Right. Millions of years of programming language design have shown us how to write a loop with the condition tested at the end -- the condition is written after the loop body. With PEP 315, a do-while loop would look like: do: body while cond: pass But then, I'm reasonably happy with the 'break out of an infinite loop' approach, so *shrug*. Amen. If we have to do this, PEP 315 has my +0. It is Pythonically minimal and the motivation rings true: I've often written code like this in the past: line = f.readline() while line: do something line = f.readline() But these days we do that using for line in f. I wonder if other similar use cases can't be rewritten using better iterators? Maybe Raymond can show us some motivating use cases. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Wishlist: dowhile
Nick Coghlan [EMAIL PROTECTED] wrote: Raymond Hettinger wrote: More than case-statement semantics or PEP343, I wish for a dowhile statement. The most straight-forward way is to put the conditional expression at the beginning of the block with the understanding that a dowhile keyword will evaluate the condition only after the block runs Out-of-order code execution rarely counts as 'straightforward' ;) With PEP 315, a do-while loop would look like: do: body while cond: pass But then, I'm reasonably happy with the 'break out of an infinite loop' approach, so *shrug*. PEP 315 offers the creation/use of an additional keyword. It also happens to push the condition to the end of the loop body. I'm not sure that pushing condition evaluation to the end of the loop body (with a trailing 'pass' as provided) is necessarily more readable than Raymond's offered dowhile. In fact, if I remember the discussion over decorators correctly, putting an operation later actually reduces readability, though at least in this case, the bare do: would signal to the user Hey, I have a condition later! Though we again run into, how is that any better than having the condition at the front to begin with, especially if a new keyword is necessary regardless of the resulting syntax? - Josiah ___ 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] Wishlist: dowhile
At 09:01 PM 6/12/2005 -0700, Guido van Rossum wrote: If we have to do this, PEP 315 has my +0. It is Pythonically minimal and the motivation rings true: I've often written code like this in the past: line = f.readline() while line: do something line = f.readline() But these days we do that using for line in f. Block-copying a file with read() has the same pattern (e.g. in shutil), but you can't make it a for loop. By the way, whatever happened to and while? i.e.: while True: data = inp.read(blocksize) and while data: out.write(data) It seemed to me this variation of the syntax had some traction at one point. Anyway, most of the times that I'm annoyed by the current while loop's limitations are due to the need to write things like the above as: while True: data = inp.read(blocksize) if not data: break out.write(data) Which makes it a bit harder to see the control flow. Or more precisely, something like the 'do/while' or 'while/and while' would make it *easier* to see the control flow, since really while isn't *bad*. I seem to recall that Knuth had something to say about the ideal loop being one that allowed you to execute code both before and after the exit condition, and that many languages allow you to have code before, or code after, but few allow you to do both in the same loop, forcing you to either duplicate some code or restructure your approach in order to fit the limitation of the language. ___ 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
