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=glance&s=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" Calvin&Hobbes ___ 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] Post-EuroPython 2005 PyPy Sprint 1st - 7th July 2005
Post-EuroPython 2005 PyPy Sprint 1st - 7th July 2005 == The next PyPy sprint is scheduled right after EuroPython 2005 in Gothenborg, Sweden. Its main focus is translation to lower level backends but there are also other possible topics. We'll give newcomer-friendly introductions. To learn more about the new PyPy Python-in-Python implementation look here: http://codespeak.net/pypy On a side note, there are a number of sub projects that may be interesting for participating in google's summer-of-code event (deadline June 14th!). The PyPy group is willing to mentor projects that have some link with PyPy, so if you are accepted in such a project, the sprint could also serve as a good meeting and kick-off point. Further down you'll find some examples, but there are certainly more and bigger ones :-) Goals and topics of the sprint -- The main, though not the only, focus of the sprint will be on the "translation" aspect of PyPy. The goal here is to progress towards a completely translated PyPy. How much will already have been done before EuroPython is unknown; as a guess, we will be left with: - completing the "rtyper", the piece of code that assigns low-level C-like types to high-level RPython objects (lists, dicts, instances, etc.) and low-level control flow graphs to high-level ones; - polish off the GenC and GenLLVM back-ends, responsible for turning the low-level C-like flow graphs into real C or LLVM source code. See http://codespeak.net/pipermail/pypy-dev/2005q2/002136.html for more information (10th of June status). Non-translation-related topics are welcome too. Here are some suggestions from the issue tracker (https://codespeak.net/issue/pypy-dev/): - integrate the parser module, possibly making it RPython conformant; - rewrite in Python a C module you are familiar with (partial list of missing/incomplete modules: os, math, array, regular expressions, binascii...) - implement Python 2.3's import hook extensions (zip-imports etc.) - fix Windows-related issues, '%'-formatting rounding errors, add missing docstrings on app-level built-in types and functions, etc. - weakrefs (but this requires discussion and planning on pypy-dev before the sprint! feel free to start such a discussion, though.) Location & Accomodation The sprint will be held in the former Math Center building near the crossing of Gibraltargatan and Eklandagatan. Entrance is on the middle of the side facing Gibraltargatan. The doors to the building are normally locked, so you need the phone number of somebody inside to get in. Instructions on whom to call will be posted on the door. The sprint will be co-located with several other sprints. See the `EuroPython Wiki`_, to find out what other sprints will be running. Nearest, and probably cheapest is to book accomodation at SGS Veckobostäder through the Europython website. This option will be available until about 20 June. .. _`EuroPython special accomodation`: http://www.europython.org/sections/accomodation/special_accomodation .. _`EuroPython Wiki`: http://www.europython.org/sections/sprints_and_wiki Exact times --- The public Pypy sprint is held Friday 1st July - Thursday 7 July 2005. Hours will be from 09:00 until people have had enough. It's a good idea to arrive a day before the sprint starts. (There is a sprint for people who are familiar with the Pypy codebase before Europython as well. This will be held at Jacob & Laura's home on Götabergsgatan 22.) Network, Food, currency Sweden is not part of the Euro zone. One SEK (krona in singular, kronor in plural) is roughly 1/10th of a Euro (9.15 SEK to 1 Euro). There are some pizzerias, kebab places and the like close to the venue. Their food is edible and cheap, but not very good. For good food, you need to go downtown. You need a wireless network card to access the network. You will be issued a login to the Chalmers NOMAD network. This will allow you to use access points all over Chalmers. However, we can likely provide a wireless/ethernet bridge. Sweden uses the same kind of plugs as Germany. 230V AC. Registration etc.pp. Please subscribe to the `PyPy sprint mailing list`_, introduce yourself and post a note that you want to come. Feel free to ask any questions there! .. _`PyPy sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint -- Armin Rigo & the PyPy team ___ 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
[Python-Dev] Wishlist: dowhile
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: dowhile : being the equivalent of; _firstpass = True while _firstpass or : _firstpass = False 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] 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: while : 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] Multiple expression eval in compound if statement?
On Jun 12, 2005, at 10:20 PM, Raymond Hettinger wrote: > 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). Yes, changing the semantics of the if statement would be pretty bad. Unless evaluating x provably has no side effects (e.g. accessing a local variable), I would say that the duplicate evaluations must not be eliminated. >> if x == 1: >> print 1 >> elif x == 2: >> print 2 >> else: >> print "unknown" Unfortunately, I'm afraid this will not be as useful as it at first appears, because python has no concept of a constant variable binding. I hardly ever see an if/else chain being done with hardcoded integers. Rather, more often a variable is compared to global "constants", which could not be optimized away. However, this construction does appear reasonably often with constant strings on the RHS, so there may actually be a real-world gain to be had. With a Sufficiently Smart Compiler, of course, you could make assumptions at runtime about values not changing, and recompile code depending upon that assumption if necessary, but that's more in the realm of a new runtime than modifications to CPython. Maybe PyPy will eventually provide the ability to do that kind of interesting optimization. James ___ 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: > >while : >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: 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: > >while : >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: > > 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
Re: [Python-Dev] Wishlist: dowhile
> By the way, whatever happened to "and while"? That is making something hard and weird out of something simple. There were no shortage of odd suggestions to force the condition line to appear lower in the block than the starting line. All of them smelled of rotten eggs -- they just don't fit the Python mold. In contrast, the dowhile solution only takes about 30 seconds to get used to. Maybe that idea should follow the path of the genexp PEP, get rejected now, and then get resurrected as a bright idea two years from now. Or maybe not. 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
