From andre.roberge at gmail.com Tue Jul 1 00:00:14 2008 From: andre.roberge at gmail.com (Andre Roberge) Date: Mon, 30 Jun 2008 19:00:14 -0300 Subject: [Python-ideas] Reducing colon uses to increase readability In-Reply-To: References: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com> Message-ID: <7528bcdd0806301500h5cd94f78w3bbbc92c02e119d9@mail.gmail.com> On Mon, Jun 30, 2008 at 6:34 PM, Leif Walsh wrote: > On Sun, Jun 29, 2008 at 6:41 PM, Andre Roberge wrote: [snip] >> I would argue that, in these last three examples, there might be better choices. >> (some of these choices have been inspired by reading >> http://www.resolversystems.com/documentation/index.php/Differences_Between_Resolver_One%27s_Formula_Language_and_Python_Expressions) > > Are you suggesting this because you work with both languages? This > e-mail seems a bit self-serving, because of the inclusion of someone's > in-house language spec. > Nope, never used it. I try, whenever I can, to always give credit to the relevant source when I mention something that may appear to be an original idea - hence the above reference. [snip] > > That said, I'm not sure 'arrows' are even the right approach for > slices. Slices should be thought of as ranges, which usually lend > themselves to ellipses. I remember (loosely, from a long time ago) > Ruby having '..' and '...' as exclusive and inclusive ranges, and I > really liked that. > [snip] >> >> I have seen other alternatives for simple slices suggested in the past such as >> [a..b] and [a...b] which would be the equivalent of [a->b] and [a=>b]; >> however, the extra "." might sometimes be difficult to read, whereas >> the difference between "->" and "=>" is much easier to see. > > You're right. This is one of the reasons I hate Ruby. Yet another > reason to ignore your suggestion for slices :-). > Hmm... this is one of the reason you really like it (see above) and hate it too! ;-) Sorry, I couldn't resist ;-) Cheers, Andr? > -- > Cheers, > Leif > From leif.walsh at gmail.com Tue Jul 1 00:04:39 2008 From: leif.walsh at gmail.com (Leif Walsh) Date: Mon, 30 Jun 2008 15:04:39 -0700 Subject: [Python-ideas] Reducing colon uses to increase readability In-Reply-To: <7528bcdd0806301500h5cd94f78w3bbbc92c02e119d9@mail.gmail.com> References: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com> <7528bcdd0806301500h5cd94f78w3bbbc92c02e119d9@mail.gmail.com> Message-ID: On Mon, Jun 30, 2008 at 3:00 PM, Andre Roberge wrote: >> That said, I'm not sure 'arrows' are even the right approach for >> slices. Slices should be thought of as ranges, which usually lend >> themselves to ellipses. I remember (loosely, from a long time ago) >> Ruby having '..' and '...' as exclusive and inclusive ranges, and I >> really liked that. >> > [snip] >>> >>> I have seen other alternatives for simple slices suggested in the past such as >>> [a..b] and [a...b] which would be the equivalent of [a->b] and [a=>b]; >>> however, the extra "." might sometimes be difficult to read, whereas >>> the difference between "->" and "=>" is much easier to see. >> >> You're right. This is one of the reasons I hate Ruby. Yet another >> reason to ignore your suggestion for slices :-). >> > Hmm... this is one of the reason you really like it (see above) and > hate it too! ;-) > > Sorry, I couldn't resist ;-) Teach me a lesson inconsistency, will you! Yeah, what I meant was that the math side of me really liked using ellipses to mark ranges, but the reading side of me hated figuring out the difference between '..' and '...'. I'd say forget about the inclusive/exclusive part, keep that the way it is now, and just change the colon to '...', if we decide to change anything about slices, which I'm not convinced is necessary. -- Cheers, Leif From andrew at atoulou.se Tue Jul 1 04:34:23 2008 From: andrew at atoulou.se (Andrew Toulouse) Date: Mon, 30 Jun 2008 19:34:23 -0700 Subject: [Python-ideas] Reducing colon uses to increase readability In-Reply-To: References: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com> <7528bcdd0806301500h5cd94f78w3bbbc92c02e119d9@mail.gmail.com> Message-ID: Actually, I found : very clear as a newcomer to Python -- and you might laugh at me for this -- because it corresponded with my visualization of slices as, literally, vertical 'cuts' in the list. : is symmetrical and straight up-and-down, and for whatever reason this is what works for me when trying to visualize the slice. I took on a job tutoring Python to students at Berkeley over the past two semesters, using this analogy (: doing the 'cutting': i.e. start at index 'start', cut, and take the rest until index 'end') worked, and : never got in the way. Using -> or .. would possibly help the mathematically-oriented people, but we get a lot of people from different walks of life, and I don't know that -> or .. would really help. Also, the difference between -> and => is one line and a whole lot of confusion. Given the ability to use ranges that may or may not include the last element, that means for basically *every* given tuple, you can slice it the same way with two different notations (by adding one to the exclusive one, or subtracting one from the inclusive one). It's a terrible idea, because now you have two ways to do the same thing, and a terrible symbol to differentiate them: -> and => are both arrows, and there is no way I'm going to remember which is which if I'm not constantly using them -- and certainly not non-programming types. "There should be one-- and preferably only one --obvious way to do it." -- or else you get a bunch of conversations like so: "well, you did it this way, why didn't you do it that way?" "well, you can do it either way, actually." "so they mean the same thing?" "not quite, one's inclusive, one's exclusive, like I explained." "which one was which again?" "sigh" rinse and repeat. I really don't see the problem with ':'. It's straightforward enough that even humanities majors (ahem, engineering major, forgive the snobbishness) get used to it after 10-15 minutes of face-to-face tutoring and examples. Changing the notation would at best save 5 minutes of tutoring time and piss off everyone who is either used to colon notation or actually *likes* it (like me), and at worst, add on a few extra minutes and *still* piss off everyone who is either used to colon notation or actually likes it. Not to mention you'd have to change the syntax and render all the code that uses slicing useless, pissing off untold legions of Python programmers. That is, unless you make it an optional syntax alongside the original, in which case you again have the (IMO, unpleasant) situation of being able to express the same thing in many ways. You'll have code that gets mixed together which uses one or the other, so now you're forcing people to know both ways of doing the same thing and being able to switch between both syntaxes when reviewing the code. Bad bad bad. I just can't see this happening. I don't believe it has any merits except to possibly increase readability, and I take issue with the idea that it would in fact do so. Add to that the huge pain this would be either as a replacement syntax or as an optional syntax, and I think it would actually be a terrible idea. --Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnodel at googlemail.com Tue Jul 1 08:09:20 2008 From: arnodel at googlemail.com (Arnaud Delobelle) Date: Tue, 1 Jul 2008 07:09:20 +0100 Subject: [Python-ideas] Reducing colon uses to increase readability In-Reply-To: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com> References: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com> Message-ID: <9F1B7277-7E7D-4F41-998F-0A26BE426FC1@googlemail.com> On 30 Jun 2008, at 02:41, Andre Roberge wrote: > dict assignments > ------------------------ > > Here again, I would argue that using "->" instead of ":" would make > the code more readable - at least for beginners. > > numbers = {'one' -> 1, 'two' -> 2} instead of > numbers = {'one': 1, 'two': 2} > I don't find the first version more readable. I find it noisier. > lambda assignments > --------------------------- > > Once again, same choice. > > lambda x -> x+1 > is, I think, more readable than > lambda x: x+1 > > (but perhaps the last two [dicts and lambda] largely depends on the > font choice...) You could even drop the 'lambda' and simply write: x -> x+1 This would please those who advocate the removal of lambda from the language ;) -- Arnaud From tjreedy at udel.edu Tue Jul 1 20:44:11 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 01 Jul 2008 14:44:11 -0400 Subject: [Python-ideas] Reducing colon uses to increase readability In-Reply-To: References: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com> <7528bcdd0806301500h5cd94f78w3bbbc92c02e119d9@mail.gmail.com> Message-ID: Andrew Toulouse wrote: > Actually, I found : very clear as a newcomer to Python -- and you might > laugh at me for this -- because it corresponded with my visualization of > slices as, literally, vertical 'cuts' in the list. On the contrary, I have advised people for years (in c.l.p posts) to realize that 0,1,...n-1,n number the n+1 slice positions before, between, and after the n items, which correspond to the possible positions of vertical bar cursors. > : is symmetrical and > straight up-and-down, and for whatever reason this is what works for me > when trying to visualize the slice. Thanks for pointing out that : is as close to | as possible in essential characteristics without being |. (The latter, of course, already being used for bitwise not and in other languages, doubled for logical not.) tjr From rnd at onego.ru Thu Jul 3 14:06:40 2008 From: rnd at onego.ru (Roman Susi) Date: Thu, 03 Jul 2008 15:06:40 +0300 Subject: [Python-ideas] Implicit lambda Re: Reducing colon uses to increase readability In-Reply-To: <9F1B7277-7E7D-4F41-998F-0A26BE426FC1@googlemail.com> References: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com> <9F1B7277-7E7D-4F41-998F-0A26BE426FC1@googlemail.com> Message-ID: <486CC0D0.1010902@onego.ru> Arnaud Delobelle wrote: > > On 30 Jun 2008, at 02:41, Andre Roberge wrote: >> lambda assignments >> --------------------------- >> >> Once again, same choice. >> >> lambda x -> x+1 >> is, I think, more readable than >> lambda x: x+1 >> >> (but perhaps the last two [dicts and lambda] largely depends on the >> font choice...) > > You could even drop the 'lambda' and simply write: > > x -> x+1 > > This would please those who advocate the removal of lambda from the > language ;) > While I'd hate -> or <- being used in Python syntax (regardless where) (I think, := for assignment might be less evil). However, changing the topic, the idea of dropping lambda in some cases was already raised: http://www.python.org/dev/peps/pep-0312/ (still deferred). The implicit lambda is then more like a quote in Lisp, roughly: "things which aren't yet evaluated". I understood that the PEP312 was perceived as a partial case for the inline if-then-else and soon forgotten (when inline if made it into Python). Maybe its time to look at those lambdas again to see if there is some value in the lambdas without the word lambda? (N.B. The things has been already discussed couple of times and even backed by some Python developers: http://mail.python.org/pipermail/python-dev/2005-June/054303.html and even some later discussions occured: http://osdir.com/ml/python.python-3000.devel/2006-05/msg00773.html The main idea of implicit lambda is to better support lazy evaluations. However, beyond obvious simple cases omitting lambda makes code less readable. Regards, Roman From stavros at korokithakis.net Thu Jul 3 16:06:45 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Thu, 03 Jul 2008 17:06:45 +0300 Subject: [Python-ideas] "While" suggestion Message-ID: <486CDCF5.6080805@korokithakis.net> Hello all, I have noticed that sometimes "while" loops produce "unpythonic" patterns, such as the following: data = my_file.read(1024) while data: do_something(data) data = my_file.read(1024) The assignment is repeated, which is less than optimal. Since we don't have a while statement that does the check in the end, would it not be better if the syntax of while could be amended to include something like this (in the spirit of the new "with" keyword)?: while my_file.read(1024) as data: do_something(data) This would terminate the loop when myfile.read() evaluated to False, and it is more pythonic than repeating onesself. I contacted GvR about this, and he replied that this syntax would have to be part of the expression than part of the while, which I agree would be less than ideal. However, I don't see why it would have to be part of the expression, since the "while" could easily assign the value of the expression to the variable and break if it evaluates to False. I would appreciate any thoughts on this, Stavros Korokithakis -------------- next part -------------- A non-text attachment was scrubbed... Name: stavros.vcf Type: text/x-vcard Size: 143 bytes Desc: not available URL: From stavros at korokithakis.net Thu Jul 3 16:24:31 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Thu, 03 Jul 2008 17:24:31 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CE075.3000104@vector-seven.com> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> Message-ID: <486CE11F.50601@korokithakis.net> I don't think they do, if I'm not mistaken the only way is to call read() and see if it returns the empty string. I agree that this would be better, but the use case I mentioned is not the only one this would be useful in... Unfortunately I can't think of any right now, but there have been a few times when I had to initialise things outside the loop and it always strikes me as ugly. Thomas Lee wrote: > It's not currently possible to determine if a file/stream is at its end, > is it? > > If that were the case you could easily do the read before your > do_something call. Something like: > > while not my_file.eof: > data = my_file.read(1024) > do_something(data) > > Can anyone explain why file objects don't support some sort of eof > check? Something gives me the impression that it was an intentional > decision. > > IMO something like this would be better than more syntax. > > Cheers, > T > > Stavros Korokithakis wrote: >> Hello all, >> I have noticed that sometimes "while" loops produce "unpythonic" >> patterns, such as the following: >> >> data = my_file.read(1024) >> while data: >> do_something(data) >> data = my_file.read(1024) >> >> The assignment is repeated, which is less than optimal. Since we don't >> have a while statement that does the check in the end, would it not be >> better if the syntax of while could be amended to include something >> like this (in the spirit of the new "with" keyword)?: >> >> while my_file.read(1024) as data: >> do_something(data) >> >> This would terminate the loop when myfile.read() evaluated to False, >> and it is more pythonic than repeating onesself. >> >> I contacted GvR about this, and he replied that this syntax would have >> to be part of the expression than part of the while, which I agree >> would be less than ideal. However, I don't see why it would have to be >> part of the expression, since the "while" could easily assign the >> value of the expression to the variable and break if it evaluates to >> False. >> >> I would appreciate any thoughts on this, >> Stavros Korokithakis >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> http://mail.python.org/mailman/listinfo/python-ideas >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: stavros.vcf Type: text/x-vcard Size: 143 bytes Desc: not available URL: From tom at vector-seven.com Thu Jul 3 16:21:41 2008 From: tom at vector-seven.com (Thomas Lee) Date: Fri, 04 Jul 2008 00:21:41 +1000 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CDCF5.6080805@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> Message-ID: <486CE075.3000104@vector-seven.com> It's not currently possible to determine if a file/stream is at its end, is it? If that were the case you could easily do the read before your do_something call. Something like: while not my_file.eof: data = my_file.read(1024) do_something(data) Can anyone explain why file objects don't support some sort of eof check? Something gives me the impression that it was an intentional decision. IMO something like this would be better than more syntax. Cheers, T Stavros Korokithakis wrote: > Hello all, > I have noticed that sometimes "while" loops produce "unpythonic" > patterns, such as the following: > > data = my_file.read(1024) > while data: > do_something(data) > data = my_file.read(1024) > > The assignment is repeated, which is less than optimal. Since we don't > have a while statement that does the check in the end, would it not be > better if the syntax of while could be amended to include something > like this (in the spirit of the new "with" keyword)?: > > while my_file.read(1024) as data: > do_something(data) > > This would terminate the loop when myfile.read() evaluated to False, > and it is more pythonic than repeating onesself. > > I contacted GvR about this, and he replied that this syntax would have > to be part of the expression than part of the while, which I agree > would be less than ideal. However, I don't see why it would have to be > part of the expression, since the "while" could easily assign the > value of the expression to the variable and break if it evaluates to > False. > > I would appreciate any thoughts on this, > Stavros Korokithakis > ------------------------------------------------------------------------ > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > From facundobatista at gmail.com Thu Jul 3 16:46:51 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Thu, 3 Jul 2008 11:46:51 -0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CDCF5.6080805@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> Message-ID: 2008/7/3 Stavros Korokithakis : > while my_file.read(1024) as data: > do_something(data) Python explicitly disallows inline assignment ("while a=myfile.read():") because of the error propensity when confusing it with the comparation ("=="). But here we're gaining the same advantage, without that risk. So, taking into account that... a) We already have "as" as an statement. b) We already use "as" as an assignment [1] c) This will allow more concise and intuitive code ... I'm definitely +1 to this proposition. In any case, Stavros, this would need a PEP... Thank you! [1] http://docs.python.org/dev/reference/compound_stmts.html#the-with-statement -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From josiah.carlson at gmail.com Thu Jul 3 16:50:53 2008 From: josiah.carlson at gmail.com (Josiah Carlson) Date: Thu, 3 Jul 2008 07:50:53 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CE11F.50601@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> Message-ID: There doesn't really exist an "end of file" unless you are using a stream (pipe, socket, ...). Real files can be appended to at any time on the three major platforms. Also, if you know that you are going to be reading blocked data, perhaps it's better just to write your blocked reader (with your single non-pythonic idiom) once. def blocked_reader(handle, blocksize=4096): data = handle.read(blocksize) while data: yield data data = handle.read(blocksize) Then you can use a better common idiom than a while loop: for block in blocked_reader(handle): handle_data(block) - Josiah On Thu, Jul 3, 2008 at 7:24 AM, Stavros Korokithakis wrote: > I don't think they do, if I'm not mistaken the only way is to call read() > and see if it returns the empty string. I agree that this would be better, > but the use case I mentioned is not the only one this would be useful in... > Unfortunately I can't think of any right now, but there have been a few > times when I had to initialise things outside the loop and it always strikes > me as ugly. > > Thomas Lee wrote: >> >> It's not currently possible to determine if a file/stream is at its end, >> is it? >> >> If that were the case you could easily do the read before your >> do_something call. Something like: >> >> while not my_file.eof: >> data = my_file.read(1024) >> do_something(data) >> >> Can anyone explain why file objects don't support some sort of eof check? >> Something gives me the impression that it was an intentional decision. >> >> IMO something like this would be better than more syntax. >> >> Cheers, >> T >> >> Stavros Korokithakis wrote: >>> >>> Hello all, >>> I have noticed that sometimes "while" loops produce "unpythonic" >>> patterns, such as the following: >>> >>> data = my_file.read(1024) >>> while data: >>> do_something(data) >>> data = my_file.read(1024) >>> >>> The assignment is repeated, which is less than optimal. Since we don't >>> have a while statement that does the check in the end, would it not be >>> better if the syntax of while could be amended to include something like >>> this (in the spirit of the new "with" keyword)?: >>> >>> while my_file.read(1024) as data: >>> do_something(data) >>> >>> This would terminate the loop when myfile.read() evaluated to False, and >>> it is more pythonic than repeating onesself. >>> >>> I contacted GvR about this, and he replied that this syntax would have to >>> be part of the expression than part of the while, which I agree would be >>> less than ideal. However, I don't see why it would have to be part of the >>> expression, since the "while" could easily assign the value of the >>> expression to the variable and break if it evaluates to False. >>> >>> I would appreciate any thoughts on this, >>> Stavros Korokithakis >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> http://mail.python.org/mailman/listinfo/python-ideas >>> >> > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > > From stavros at korokithakis.net Thu Jul 3 16:51:42 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Thu, 03 Jul 2008 17:51:42 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> Message-ID: <486CE77E.5050407@korokithakis.net> Hmm, I have no idea how to write a PEP, but if more people are amenable to this, I will endeavour to! Thanks for your feedback, Stavros Facundo Batista wrote: > 2008/7/3 Stavros Korokithakis : > >> while my_file.read(1024) as data: >> do_something(data) > > Python explicitly disallows inline assignment ("while > a=myfile.read():") because of the error propensity when confusing it > with the comparation ("=="). But here we're gaining the same > advantage, without that risk. > > So, taking into account that... > > a) We already have "as" as an statement. > > b) We already use "as" as an assignment [1] > > c) This will allow more concise and intuitive code > > ... I'm definitely +1 to this proposition. > > In any case, Stavros, this would need a PEP... > > Thank you! > > [1] http://docs.python.org/dev/reference/compound_stmts.html#the-with-statement > -------------- next part -------------- A non-text attachment was scrubbed... Name: stavros.vcf Type: text/x-vcard Size: 143 bytes Desc: not available URL: From josiah.carlson at gmail.com Thu Jul 3 16:54:21 2008 From: josiah.carlson at gmail.com (Josiah Carlson) Date: Thu, 3 Jul 2008 07:54:21 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> Message-ID: On Thu, Jul 3, 2008 at 7:46 AM, Facundo Batista wrote: > 2008/7/3 Stavros Korokithakis : > >> while my_file.read(1024) as data: >> do_something(data) > > Python explicitly disallows inline assignment ("while > a=myfile.read():") because of the error propensity when confusing it > with the comparation ("=="). But here we're gaining the same > advantage, without that risk. > > So, taking into account that... > > a) We already have "as" as an statement. > > b) We already use "as" as an assignment [1] > > c) This will allow more concise and intuitive code > > ... I'm definitely +1 to this proposition. > > In any case, Stavros, this would need a PEP... I would argue at a -.5. Not every 5-line function needs to be syntax, and unless someone can really show a common use-case for tossing 'as' in the syntax of the while loop, it smells like a one-off syntax. Don't get me wrong, I've needed to do blocked reading before, but I typically write the block reader generator and call it good. - Josiah From george.sakkis at gmail.com Thu Jul 3 16:55:56 2008 From: george.sakkis at gmail.com (George Sakkis) Date: Thu, 3 Jul 2008 10:55:56 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CDCF5.6080805@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> Message-ID: <91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com> On Thu, Jul 3, 2008 at 10:06 AM, Stavros Korokithakis < stavros at korokithakis.net> wrote: > Hello all, > I have noticed that sometimes "while" loops produce "unpythonic" patterns, > such as the following: > > data = my_file.read(1024) > while data: > do_something(data) > data = my_file.read(1024) > > The assignment is repeated, which is less than optimal. Since we don't have > a while statement that does the check in the end, would it not be better if > the syntax of while could be amended to include something like this (in the > spirit of the new "with" keyword)?: > > while my_file.read(1024) as data: > do_something(data) > > This would terminate the loop when myfile.read() evaluated to False, and it > is more pythonic than repeating onesself. There is already an idiom for this, although admittedly not obvious or well-known: for data in iter(lambda: my_file.read(1024), ''): do_something(data) or in 2.5+: from functools import partial for data in iter(partial(my_file.read,1024), ''): do_something(data) George -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at vector-seven.com Thu Jul 3 16:58:12 2008 From: tom at vector-seven.com (Thomas Lee) Date: Fri, 04 Jul 2008 00:58:12 +1000 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CE11F.50601@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> Message-ID: <486CE904.2040403@vector-seven.com> Stavros Korokithakis wrote: > I don't think they do, if I'm not mistaken the only way is to call > read() and see if it returns the empty string. I agree that this would > be better, but the use case I mentioned is not the only one this would > be useful in... Unfortunately I can't think of any right now, :) > but there have been a few times when I had to initialise things > outside the loop and it always strikes me as ugly. > Well that depends, on the situation really. The only use case I can think of is exactly the one you mentioned. And since you can't think of any other scenarios where such a thing might be handy, I've got no better suggestion to offer. If you can conjure up another scenario, post it back here and we'll see if we can generalize the pattern a little. In the meantime, I'd love a way to check if a file is at its end without having to read data out of it ... Cheers, T P.S. you might be interested in using something like the following to hide the ugliness in a function: def reader(stream, size): data = stream.read(size) while data: yield data data = stream.read(size) Then you could use it as follows: for block in reader(my_file, 1024): do_something(block) > Thomas Lee wrote: >> It's not currently possible to determine if a file/stream is at its >> end, is it? >> >> If that were the case you could easily do the read before your >> do_something call. Something like: >> >> while not my_file.eof: >> data = my_file.read(1024) >> do_something(data) >> >> Can anyone explain why file objects don't support some sort of eof >> check? Something gives me the impression that it was an intentional >> decision. >> >> IMO something like this would be better than more syntax. >> >> Cheers, >> T >> >> Stavros Korokithakis wrote: >>> Hello all, >>> I have noticed that sometimes "while" loops produce "unpythonic" >>> patterns, such as the following: >>> >>> data = my_file.read(1024) >>> while data: >>> do_something(data) >>> data = my_file.read(1024) >>> >>> The assignment is repeated, which is less than optimal. Since we >>> don't have a while statement that does the check in the end, would >>> it not be better if the syntax of while could be amended to include >>> something like this (in the spirit of the new "with" keyword)?: >>> >>> while my_file.read(1024) as data: >>> do_something(data) >>> >>> This would terminate the loop when myfile.read() evaluated to False, >>> and it is more pythonic than repeating onesself. >>> >>> I contacted GvR about this, and he replied that this syntax would >>> have to be part of the expression than part of the while, which I >>> agree would be less than ideal. However, I don't see why it would >>> have to be part of the expression, since the "while" could easily >>> assign the value of the expression to the variable and break if it >>> evaluates to False. >>> >>> I would appreciate any thoughts on this, >>> Stavros Korokithakis >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> Python-ideas mailing list >>> Python-ideas at python.org >>> http://mail.python.org/mailman/listinfo/python-ideas >>> >> From tom at vector-seven.com Thu Jul 3 16:59:56 2008 From: tom at vector-seven.com (Thomas Lee) Date: Fri, 04 Jul 2008 00:59:56 +1000 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CE904.2040403@vector-seven.com> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> Message-ID: <486CE96C.90306@vector-seven.com> Oops. George and Facundo beat me to the iterator suggestion. :) Cheers, T Thomas Lee wrote: > Stavros Korokithakis wrote: >> I don't think they do, if I'm not mistaken the only way is to call >> read() and see if it returns the empty string. I agree that this >> would be better, but the use case I mentioned is not the only one >> this would be useful in... Unfortunately I can't think of any right now, > :) >> but there have been a few times when I had to initialise things >> outside the loop and it always strikes me as ugly. >> > Well that depends, on the situation really. The only use case I can > think of is exactly the one you mentioned. And since you can't think > of any other scenarios where such a thing might be handy, I've got no > better suggestion to offer. > > If you can conjure up another scenario, post it back here and we'll > see if we can generalize the pattern a little. > > In the meantime, I'd love a way to check if a file is at its end > without having to read data out of it ... > > Cheers, > T > > P.S. you might be interested in using something like the following to > hide the ugliness in a function: > > def reader(stream, size): > data = stream.read(size) > while data: > yield data > data = stream.read(size) > > Then you could use it as follows: > > for block in reader(my_file, 1024): > do_something(block) >> Thomas Lee wrote: >>> It's not currently possible to determine if a file/stream is at its >>> end, is it? >>> >>> If that were the case you could easily do the read before your >>> do_something call. Something like: >>> >>> while not my_file.eof: >>> data = my_file.read(1024) >>> do_something(data) >>> >>> Can anyone explain why file objects don't support some sort of eof >>> check? Something gives me the impression that it was an intentional >>> decision. >>> >>> IMO something like this would be better than more syntax. >>> >>> Cheers, >>> T >>> >>> Stavros Korokithakis wrote: >>>> Hello all, >>>> I have noticed that sometimes "while" loops produce "unpythonic" >>>> patterns, such as the following: >>>> >>>> data = my_file.read(1024) >>>> while data: >>>> do_something(data) >>>> data = my_file.read(1024) >>>> >>>> The assignment is repeated, which is less than optimal. Since we >>>> don't have a while statement that does the check in the end, would >>>> it not be better if the syntax of while could be amended to >>>> include something like this (in the spirit of the new "with" >>>> keyword)?: >>>> >>>> while my_file.read(1024) as data: >>>> do_something(data) >>>> >>>> This would terminate the loop when myfile.read() evaluated to >>>> False, and it is more pythonic than repeating onesself. >>>> >>>> I contacted GvR about this, and he replied that this syntax would >>>> have to be part of the expression than part of the while, which I >>>> agree would be less than ideal. However, I don't see why it would >>>> have to be part of the expression, since the "while" could easily >>>> assign the value of the expression to the variable and break if it >>>> evaluates to False. >>>> >>>> I would appreciate any thoughts on this, >>>> Stavros Korokithakis >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas at python.org >>>> http://mail.python.org/mailman/listinfo/python-ideas >>>> >>> > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas From stavros at korokithakis.net Thu Jul 3 17:01:26 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Thu, 03 Jul 2008 18:01:26 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> Message-ID: <486CE9C6.7080503@korokithakis.net> The proposed syntax would be (mostly) equivalent to C's do ... while loop without adding another looping construct, so the usefulness would be that of do ... while. I'm not sure whether everyone considers this to be indispensable, but it can't be totally useless if it was included in C... Stavros Korokithakis Josiah Carlson wrote: > On Thu, Jul 3, 2008 at 7:46 AM, Facundo Batista > wrote: >> 2008/7/3 Stavros Korokithakis : >> >>> while my_file.read(1024) as data: >>> do_something(data) >> Python explicitly disallows inline assignment ("while >> a=myfile.read():") because of the error propensity when confusing it >> with the comparation ("=="). But here we're gaining the same >> advantage, without that risk. >> >> So, taking into account that... >> >> a) We already have "as" as an statement. >> >> b) We already use "as" as an assignment [1] >> >> c) This will allow more concise and intuitive code >> >> ... I'm definitely +1 to this proposition. >> >> In any case, Stavros, this would need a PEP... > > I would argue at a -.5. Not every 5-line function needs to be syntax, > and unless someone can really show a common use-case for tossing 'as' > in the syntax of the while loop, it smells like a one-off syntax. > > Don't get me wrong, I've needed to do blocked reading before, but I > typically write the block reader generator and call it good. > > - Josiah -------------- next part -------------- A non-text attachment was scrubbed... Name: stavros.vcf Type: text/x-vcard Size: 143 bytes Desc: not available URL: From stavros at korokithakis.net Thu Jul 3 17:09:13 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Thu, 03 Jul 2008 18:09:13 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CE904.2040403@vector-seven.com> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> Message-ID: <486CEB99.6070602@korokithakis.net> This was apparently resuggested in PEP 315 but they couldn't get the syntax right: http://www.python.org/dev/peps/pep-0315/ I believe that my proposal deals with that issue by keeping the syntax coherent with the rest of Python (especially with the "with" keyword) and has all the advantages of the restructured code. There are also some use cases in that PEP. Stavros Thomas Lee wrote: > Stavros Korokithakis wrote: >> I don't think they do, if I'm not mistaken the only way is to call >> read() and see if it returns the empty string. I agree that this would >> be better, but the use case I mentioned is not the only one this would >> be useful in... Unfortunately I can't think of any right now, > :) >> but there have been a few times when I had to initialise things >> outside the loop and it always strikes me as ugly. >> > Well that depends, on the situation really. The only use case I can > think of is exactly the one you mentioned. And since you can't think of > any other scenarios where such a thing might be handy, I've got no > better suggestion to offer. > > If you can conjure up another scenario, post it back here and we'll see > if we can generalize the pattern a little. > > In the meantime, I'd love a way to check if a file is at its end without > having to read data out of it ... > > Cheers, > T > > P.S. you might be interested in using something like the following to > hide the ugliness in a function: > > def reader(stream, size): > data = stream.read(size) > while data: > yield data > data = stream.read(size) > > Then you could use it as follows: > > for block in reader(my_file, 1024): > do_something(block) >> Thomas Lee wrote: >>> It's not currently possible to determine if a file/stream is at its >>> end, is it? >>> >>> If that were the case you could easily do the read before your >>> do_something call. Something like: >>> >>> while not my_file.eof: >>> data = my_file.read(1024) >>> do_something(data) >>> >>> Can anyone explain why file objects don't support some sort of eof >>> check? Something gives me the impression that it was an intentional >>> decision. >>> >>> IMO something like this would be better than more syntax. >>> >>> Cheers, >>> T >>> >>> Stavros Korokithakis wrote: >>>> Hello all, >>>> I have noticed that sometimes "while" loops produce "unpythonic" >>>> patterns, such as the following: >>>> >>>> data = my_file.read(1024) >>>> while data: >>>> do_something(data) >>>> data = my_file.read(1024) >>>> >>>> The assignment is repeated, which is less than optimal. Since we >>>> don't have a while statement that does the check in the end, would >>>> it not be better if the syntax of while could be amended to include >>>> something like this (in the spirit of the new "with" keyword)?: >>>> >>>> while my_file.read(1024) as data: >>>> do_something(data) >>>> >>>> This would terminate the loop when myfile.read() evaluated to False, >>>> and it is more pythonic than repeating onesself. >>>> >>>> I contacted GvR about this, and he replied that this syntax would >>>> have to be part of the expression than part of the while, which I >>>> agree would be less than ideal. However, I don't see why it would >>>> have to be part of the expression, since the "while" could easily >>>> assign the value of the expression to the variable and break if it >>>> evaluates to False. >>>> >>>> I would appreciate any thoughts on this, >>>> Stavros Korokithakis >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas at python.org >>>> http://mail.python.org/mailman/listinfo/python-ideas >>>> >>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: stavros.vcf Type: text/x-vcard Size: 143 bytes Desc: not available URL: From cvrebert at gmail.com Thu Jul 3 17:14:57 2008 From: cvrebert at gmail.com (Chris Rebert) Date: Thu, 3 Jul 2008 08:14:57 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CE904.2040403@vector-seven.com> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> Message-ID: <47c890dc0807030814v55449235ucc6d08d6249216f7@mail.gmail.com> The alternate idiom I've seen for "do-while"-like loops such as this in Python is (using the original example): while True: data = my_file.read(1024) if not data: break do_something(data) which seems perfectly acceptable and in keeping with TOOWTDI by minimizing the number of loop constructs in the language. It obviously avoids the distasteful duplication of "data = my_file.read(1024)". - Chris On Thu, Jul 3, 2008 at 7:58 AM, Thomas Lee wrote: > Stavros Korokithakis wrote: >> >> I don't think they do, if I'm not mistaken the only way is to call read() >> and see if it returns the empty string. I agree that this would be better, >> but the use case I mentioned is not the only one this would be useful in... >> Unfortunately I can't think of any right now, > > :) >> >> but there have been a few times when I had to initialise things outside >> the loop and it always strikes me as ugly. >> > Well that depends, on the situation really. The only use case I can think of > is exactly the one you mentioned. And since you can't think of any other > scenarios where such a thing might be handy, I've got no better suggestion > to offer. > > If you can conjure up another scenario, post it back here and we'll see if > we can generalize the pattern a little. > > In the meantime, I'd love a way to check if a file is at its end without > having to read data out of it ... > > Cheers, > T > > P.S. you might be interested in using something like the following to hide > the ugliness in a function: > > def reader(stream, size): > data = stream.read(size) > while data: > yield data > data = stream.read(size) > > Then you could use it as follows: > > for block in reader(my_file, 1024): > do_something(block) >> >> Thomas Lee wrote: >>> >>> It's not currently possible to determine if a file/stream is at its end, >>> is it? >>> >>> If that were the case you could easily do the read before your >>> do_something call. Something like: >>> >>> while not my_file.eof: >>> data = my_file.read(1024) >>> do_something(data) >>> >>> Can anyone explain why file objects don't support some sort of eof check? >>> Something gives me the impression that it was an intentional decision. >>> >>> IMO something like this would be better than more syntax. >>> >>> Cheers, >>> T >>> >>> Stavros Korokithakis wrote: >>>> >>>> Hello all, >>>> I have noticed that sometimes "while" loops produce "unpythonic" >>>> patterns, such as the following: >>>> >>>> data = my_file.read(1024) >>>> while data: >>>> do_something(data) >>>> data = my_file.read(1024) >>>> >>>> The assignment is repeated, which is less than optimal. Since we don't >>>> have a while statement that does the check in the end, would it not be >>>> better if the syntax of while could be amended to include something like >>>> this (in the spirit of the new "with" keyword)?: >>>> >>>> while my_file.read(1024) as data: >>>> do_something(data) >>>> >>>> This would terminate the loop when myfile.read() evaluated to False, and >>>> it is more pythonic than repeating onesself. >>>> >>>> I contacted GvR about this, and he replied that this syntax would have >>>> to be part of the expression than part of the while, which I agree would be >>>> less than ideal. However, I don't see why it would have to be part of the >>>> expression, since the "while" could easily assign the value of the >>>> expression to the variable and break if it evaluates to False. >>>> >>>> I would appreciate any thoughts on this, >>>> Stavros Korokithakis >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Python-ideas mailing list >>>> Python-ideas at python.org >>>> http://mail.python.org/mailman/listinfo/python-ideas >>>> >>> > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > From stavros at korokithakis.net Thu Jul 3 17:21:07 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Thu, 03 Jul 2008 18:21:07 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: <47c890dc0807030814v55449235ucc6d08d6249216f7@mail.gmail.com> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <47c890dc0807030814v55449235ucc6d08d6249216f7@mail.gmail.com> Message-ID: <486CEE63.8050800@korokithakis.net> That is quite a bit better than duplicating the assignment, but this version duplicates the check (or rather defers it from the "while " part to the "if" part). I am not sure that it is as elegant as the proposed syntax... Stavros Chris Rebert wrote: > The alternate idiom I've seen for "do-while"-like loops such as this > in Python is (using the original example): > > while True: > data = my_file.read(1024) > if not data: break > do_something(data) > > which seems perfectly acceptable and in keeping with TOOWTDI by > minimizing the number of loop constructs in the language. > It obviously avoids the distasteful duplication of "data = my_file.read(1024)". > > - Chris > > On Thu, Jul 3, 2008 at 7:58 AM, Thomas Lee wrote: >> Stavros Korokithakis wrote: >>> I don't think they do, if I'm not mistaken the only way is to call read() >>> and see if it returns the empty string. I agree that this would be better, >>> but the use case I mentioned is not the only one this would be useful in... >>> Unfortunately I can't think of any right now, >> :) >>> but there have been a few times when I had to initialise things outside >>> the loop and it always strikes me as ugly. >>> >> Well that depends, on the situation really. The only use case I can think of >> is exactly the one you mentioned. And since you can't think of any other >> scenarios where such a thing might be handy, I've got no better suggestion >> to offer. >> >> If you can conjure up another scenario, post it back here and we'll see if >> we can generalize the pattern a little. >> >> In the meantime, I'd love a way to check if a file is at its end without >> having to read data out of it ... >> >> Cheers, >> T >> >> P.S. you might be interested in using something like the following to hide >> the ugliness in a function: >> >> def reader(stream, size): >> data = stream.read(size) >> while data: >> yield data >> data = stream.read(size) >> >> Then you could use it as follows: >> >> for block in reader(my_file, 1024): >> do_something(block) >>> Thomas Lee wrote: >>>> It's not currently possible to determine if a file/stream is at its end, >>>> is it? >>>> >>>> If that were the case you could easily do the read before your >>>> do_something call. Something like: >>>> >>>> while not my_file.eof: >>>> data = my_file.read(1024) >>>> do_something(data) >>>> >>>> Can anyone explain why file objects don't support some sort of eof check? >>>> Something gives me the impression that it was an intentional decision. >>>> >>>> IMO something like this would be better than more syntax. >>>> >>>> Cheers, >>>> T >>>> >>>> Stavros Korokithakis wrote: >>>>> Hello all, >>>>> I have noticed that sometimes "while" loops produce "unpythonic" >>>>> patterns, such as the following: >>>>> >>>>> data = my_file.read(1024) >>>>> while data: >>>>> do_something(data) >>>>> data = my_file.read(1024) >>>>> >>>>> The assignment is repeated, which is less than optimal. Since we don't >>>>> have a while statement that does the check in the end, would it not be >>>>> better if the syntax of while could be amended to include something like >>>>> this (in the spirit of the new "with" keyword)?: >>>>> >>>>> while my_file.read(1024) as data: >>>>> do_something(data) >>>>> >>>>> This would terminate the loop when myfile.read() evaluated to False, and >>>>> it is more pythonic than repeating onesself. >>>>> >>>>> I contacted GvR about this, and he replied that this syntax would have >>>>> to be part of the expression than part of the while, which I agree would be >>>>> less than ideal. However, I don't see why it would have to be part of the >>>>> expression, since the "while" could easily assign the value of the >>>>> expression to the variable and break if it evaluates to False. >>>>> >>>>> I would appreciate any thoughts on this, >>>>> Stavros Korokithakis >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Python-ideas mailing list >>>>> Python-ideas at python.org >>>>> http://mail.python.org/mailman/listinfo/python-ideas >>>>> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> http://mail.python.org/mailman/listinfo/python-ideas >> -------------- next part -------------- A non-text attachment was scrubbed... Name: stavros.vcf Type: text/x-vcard Size: 150 bytes Desc: not available URL: From facundobatista at gmail.com Thu Jul 3 17:22:16 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Thu, 3 Jul 2008 12:22:16 -0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: <91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com> References: <486CDCF5.6080805@korokithakis.net> <91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com> Message-ID: 2008/7/3 George Sakkis : > There is already an idiom for this, although admittedly not obvious or > well-known: > > for data in iter(lambda: my_file.read(1024), ''): > do_something(data) > > or in 2.5+: > > from functools import partial > for data in iter(partial(my_file.read,1024), ''): > do_something(data) Yes, but note that these feels like workarounds. One thing that I love in Python is that you can learn a concept, and apply it a lot of times. So, suppose I'm learning Python and find that I can do this... with_stmt ::= "with" expression ["as" target] ":" suite ...why can't I do this?: while_stmt ::= "while" expression ["as" target] ":" suite I mean, I don't care if this solves a lot of issues, or just a few [1]... this just make the whole syntax more coherent. Regards, [1] Note, however, that one of the issues that it solves is one that raises always a lot of questions for newbies... how to make a "do-while". -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From cvrebert at gmail.com Thu Jul 3 17:32:43 2008 From: cvrebert at gmail.com (Chris Rebert) Date: Thu, 3 Jul 2008 08:32:43 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CDCF5.6080805@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> Message-ID: <47c890dc0807030832q542b1aect7090eba7d24075b0@mail.gmail.com> On Thu, Jul 3, 2008 at 7:06 AM, Stavros Korokithakis wrote: > Hello all, > I have noticed that sometimes "while" loops produce "unpythonic" patterns, > such as the following: > > data = my_file.read(1024) > while data: > do_something(data) > data = my_file.read(1024) > > The assignment is repeated, which is less than optimal. Since we don't have > a while statement that does the check in the end, would it not be better if > the syntax of while could be amended to include something like this (in the > spirit of the new "with" keyword)?: > > while my_file.read(1024) as data: > do_something(data) What if the condition is ever so slightly more complicated? Then it looks a bit less than natural... while foo() != 17 as baz: do_something(baz) Now it looks like baz should equal the boolean value from the comparison, but what if i want it to be foo() ? And if it is somehow magically foo(), then that's really unintuitive-looking. - Chris > > This would terminate the loop when myfile.read() evaluated to False, and it > is more pythonic than repeating onesself. > > I contacted GvR about this, and he replied that this syntax would have to be > part of the expression than part of the while, which I agree would be less > than ideal. However, I don't see why it would have to be part of the > expression, since the "while" could easily assign the value of the > expression to the variable and break if it evaluates to False. > > I would appreciate any thoughts on this, > Stavros Korokithakis > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > > From tom at vector-seven.com Thu Jul 3 17:36:18 2008 From: tom at vector-seven.com (Thomas Lee) Date: Fri, 04 Jul 2008 01:36:18 +1000 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com> Message-ID: <486CF1F2.9010409@vector-seven.com> Facundo Batista wrote: > 2008/7/3 George Sakkis : > > >> There is already an idiom for this, although admittedly not obvious or >> well-known: >> >> for data in iter(lambda: my_file.read(1024), ''): >> do_something(data) >> >> or in 2.5+: >> >> from functools import partial >> for data in iter(partial(my_file.read,1024), ''): >> do_something(data) >> > > Yes, but note that these feels like workarounds. > > One thing that I love in Python is that you can learn a concept, and > apply it a lot of times. > > So, suppose I'm learning Python and find that I can do this... > > with_stmt ::= "with" expression ["as" target] ":" suite > > ...why can't I do this?: > > while_stmt ::= "while" expression ["as" target] ":" suite > > I'm -1on the while .. as syntax myself. Something about this syntax feels wrong ... it's effectively a for loop looking for a reason not to use an iterator. You might be right about it being more consistent though. Cheers, T From fdrake at acm.org Thu Jul 3 17:42:07 2008 From: fdrake at acm.org (Fred Drake) Date: Thu, 3 Jul 2008 11:42:07 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CEE63.8050800@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <47c890dc0807030814v55449235ucc6d08d6249216f7@mail.gmail.com> <486CEE63.8050800@korokithakis.net> Message-ID: <057E8E37-60FE-4B1A-B653-AF953CCDD574@acm.org> On Jul 3, 2008, at 11:21 AM, Stavros Korokithakis wrote: > That is quite a bit better than duplicating the assignment, but this > version duplicates the check (or rather defers it from the "while > " part to the "if" part). I am not sure that it is as > elegant as the proposed syntax... The style with the check "in the middle", however, is fully general: you can do different checks at different points to determine when to break or skip the rest of the indented suite; the "while as :" form only handles a specific case (though common). The "while as :" for has a certain level of attraction, because it does deal very well with a very common case, but I don't know that it would make that much difference in my code. (Of course, for the specific use case being used to seed this discussion, the fileinput module may be helpful.) -Fred -- Fred Drake From george.sakkis at gmail.com Thu Jul 3 17:42:44 2008 From: george.sakkis at gmail.com (George Sakkis) Date: Thu, 3 Jul 2008 11:42:44 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com> Message-ID: <91ad5bf80807030842l1c5607b9kbee186dce88e0796@mail.gmail.com> On Thu, Jul 3, 2008 at 11:22 AM, Facundo Batista wrote: 2008/7/3 George Sakkis : > > > There is already an idiom for this, although admittedly not obvious or > > well-known: > > > > for data in iter(lambda: my_file.read(1024), ''): > > do_something(data) > > > > or in 2.5+: > > > > from functools import partial > > for data in iter(partial(my_file.read,1024), ''): > > do_something(data) > > Yes, but note that these feels like workarounds. > > One thing that I love in Python is that you can learn a concept, and > apply it a lot of times. > > So, suppose I'm learning Python and find that I can do this... > > with_stmt ::= "with" expression ["as" target] ":" suite > > ...why can't I do this?: > > while_stmt ::= "while" expression ["as" target] ":" suite > > > I mean, I don't care if this solves a lot of issues, or just a few > [1]... this just make the whole syntax more coherent. > > Regards, > > [1] Note, however, that one of the issues that it solves is one that > raises always a lot of questions for newbies... how to make a > "do-while". Actually even more newbies look for a general assignment-as-expression (e.g. http://tinyurl.com/6bwmp2), so it's not a far step for someone to suggest for example: if_stmt ::= "if" expression ["as" target] ":" suite FWIW I am not necessarily against (rather +0 for now), I'm just pointing out that striving for coherence just for the sake of it is prone to opening a can of worms. Best, George -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundobatista at gmail.com Thu Jul 3 17:45:18 2008 From: facundobatista at gmail.com (Facundo Batista) Date: Thu, 3 Jul 2008 12:45:18 -0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: <057E8E37-60FE-4B1A-B653-AF953CCDD574@acm.org> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <47c890dc0807030814v55449235ucc6d08d6249216f7@mail.gmail.com> <486CEE63.8050800@korokithakis.net> <057E8E37-60FE-4B1A-B653-AF953CCDD574@acm.org> Message-ID: 2008/7/3 Fred Drake : > The "while as :" for has a certain level of attraction, because > it does deal very well with a very common case, but I don't know that it > would make that much difference in my code. Note that what I like in it is *not* that it solves a lot of cases, but that it makes the syntax more coherent, and solves a common case in the way, :) -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ From stavros at korokithakis.net Thu Jul 3 17:44:59 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Thu, 03 Jul 2008 18:44:59 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CF1F2.9010409@vector-seven.com> References: <486CDCF5.6080805@korokithakis.net> <91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com> <486CF1F2.9010409@vector-seven.com> Message-ID: <486CF3FB.5080907@korokithakis.net> That is true, but in this particular usage there's no iterator that would do what we wanted... I agree that it approaches the realm of the "for" statement, though. Stavros Thomas Lee wrote: > Facundo Batista wrote: >> 2008/7/3 George Sakkis : >> >> >>> There is already an idiom for this, although admittedly not obvious or >>> well-known: >>> >>> for data in iter(lambda: my_file.read(1024), ''): >>> do_something(data) >>> >>> or in 2.5+: >>> >>> from functools import partial >>> for data in iter(partial(my_file.read,1024), ''): >>> do_something(data) >>> >> >> Yes, but note that these feels like workarounds. >> >> One thing that I love in Python is that you can learn a concept, and >> apply it a lot of times. >> >> So, suppose I'm learning Python and find that I can do this... >> >> with_stmt ::= "with" expression ["as" target] ":" suite >> >> ...why can't I do this?: >> >> while_stmt ::= "while" expression ["as" target] ":" suite >> >> > I'm -1on the while .. as syntax myself. > > Something about this syntax feels wrong ... it's effectively a for loop > looking for a reason not to use an iterator. > > You might be right about it being more consistent though. > > Cheers, > T > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas -------------- next part -------------- A non-text attachment was scrubbed... Name: stavros.vcf Type: text/x-vcard Size: 143 bytes Desc: not available URL: From veloso at verylowsodium.com Thu Jul 3 17:51:23 2008 From: veloso at verylowsodium.com (Greg Falcon) Date: Thu, 3 Jul 2008 11:51:23 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CDCF5.6080805@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> Message-ID: <3cdcefb80807030851v35685f3byc7d4c7924df5a739@mail.gmail.com> On Thu, Jul 3, 2008 at 10:06 AM, Stavros Korokithakis wrote: > while my_file.read(1024) as data: > do_something(data) I dislike this for aesthetic reasons. One of the nice things about Python is that is reads like executable psuedocode. It feels more or less intuitively obvious what the various looping constructs do. I'd argue "while foo as bar" is non-obvious. I realize this syntax proposal is strongly parallel to "with foo as bar", but "with foo as bar" just seems to read better. Taken as an English clause, it gives at least a hint as to what's going on. I can imagine an experienced programmer, new to Python, seeing "while foo as bar" and assuming "as" is some sort of binary operator. This would be a minor quibble if this proposed syntax solved a problem. But as Chris Rebert points out, you can get the same effect today at the cost of two or three lines extra lines by writing it as a "while True" loop with a test and break inside. This form is only slightly longer, and is immediately obvious to programmers coming from many other languages. Greg F From stavros at korokithakis.net Thu Jul 3 18:06:22 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Thu, 03 Jul 2008 19:06:22 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: <20080703113646.1554d793@mbook.local> References: <486CDCF5.6080805@korokithakis.net> <20080703113646.1554d793@mbook.local> Message-ID: <486CF8FE.3030903@korokithakis.net> Hmm, the regular expression use case (and any other use case where you need to act based on the output of a function) looks very interesting, but I can understand how there would be a few problems with it for things like "if myfunc() > 10 as output". Still, it is worth investigating. Stavros Mike Meyer wrote: > On Thu, 3 Jul 2008 11:46:51 -0300 "Facundo Batista" wrote: > >> 2008/7/3 Stavros Korokithakis : >> >>> while my_file.read(1024) as data: >>> do_something(data) >> Python explicitly disallows inline assignment ("while >> a=myfile.read():") because of the error propensity when confusing it >> with the comparation ("=="). But here we're gaining the same >> advantage, without that risk. >> >> So, taking into account that... >> >> a) We already have "as" as an statement. >> >> b) We already use "as" as an assignment [1] >> >> c) This will allow more concise and intuitive code >> >> ... I'm definitely +1 to this proposition. >> > > I kinda like it as well. In fact, treating "as" as an assignment > operator instead of making it part of the syntax of the while > statement solves my problem with the suggestion. > > The original suggestion only dealt with a *very* special case: a loop > where 1) you needed to initialize the data before the loop started; 2) > the initialization statement was use to refresh the data in the loop, > and 3) the value of the data as a bool determined whether you wanted > to continue. > > If #3 isn't true, a while+as statement leaves you back at the original > code duplication. as as inline assignment it lets you deal with it > without the repitition: > > while my_file.read(1024) as data < 1024: > do_something_with_1k(data) > do_something_with_lessthan_1k(data) > > It also provides a nice way to deal with the long-standing ugliness > related to wanting to do repeated regular expression tests: > > if myre.match(user_input) as match: > do_something_with_matching_data(match) > elif myre2.match(user_input) as match: > do_something_else(match) > > instead of: > > match = myre.match(user_input) > if match: > do_something_with_matching_data(match) > else: > match = myre2.match(user_input) > if match: > do_something_else(match) > > which doesn't yield to the usual solution of a dict of functions. > >> In any case, Stavros, this would need a PEP... > > I'm not convinced (it ought to interact cleanly with with, but....), > but it certainly looks promising! > > +1 to at least investigating it. > > From guido at python.org Thu Jul 3 18:15:28 2008 From: guido at python.org (Guido van Rossum) Date: Thu, 3 Jul 2008 09:15:28 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <47c890dc0807030814v55449235ucc6d08d6249216f7@mail.gmail.com> <486CEE63.8050800@korokithakis.net> <057E8E37-60FE-4B1A-B653-AF953CCDD574@acm.org> Message-ID: On Thu, Jul 3, 2008 at 8:45 AM, Facundo Batista wrote: > 2008/7/3 Fred Drake : > >> The "while as :" for has a certain level of attraction, because >> it does deal very well with a very common case, but I don't know that it >> would make that much difference in my code. > > Note that what I like in it is *not* that it solves a lot of cases, > but that it makes the syntax more coherent, and solves a common case > in the way, :) That's not how I would define "coherent". It adds one more special case. See the zen of Python for that. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From python at rcn.com Thu Jul 3 18:16:05 2008 From: python at rcn.com (Raymond Hettinger) Date: Thu, 3 Jul 2008 09:16:05 -0700 Subject: [Python-ideas] "While" suggestion References: <486CDCF5.6080805@korokithakis.net> Message-ID: <1454E479AD4B49F4A52E9EA003B051F3@RaymondLaptop1> [Stavros Korokithakis] >> while my_file.read(1024) as data: >> do_something(data) [Facundo Batista] > Python explicitly disallows inline assignment ("while > a=myfile.read():") because of the error propensity when confusing it > with the comparation ("=="). But here we're gaining the same > advantage, without that risk. > > So, taking into account that... > > a) We already have "as" as an statement. > > b) We already use "as" as an assignment [1] > > c) This will allow more concise and intuitive code > > ... I'm definitely +1 to this proposition. +1 from me also. This is a simple, clean proposal. The syntax is self-explanatory and has a near zero learning curve. Raymond From janssen at parc.com Thu Jul 3 18:57:03 2008 From: janssen at parc.com (Bill Janssen) Date: Thu, 3 Jul 2008 09:57:03 PDT Subject: [Python-ideas] "While" suggestion In-Reply-To: <47c890dc0807030814v55449235ucc6d08d6249216f7@mail.gmail.com> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <47c890dc0807030814v55449235ucc6d08d6249216f7@mail.gmail.com> Message-ID: <08Jul3.095711pdt."58698"@synergy1.parc.xerox.com> > while True: > data = my_file.read(1024) > if not data: break > do_something(data) > > which seems perfectly acceptable and in keeping with TOOWTDI by > minimizing the number of loop constructs in the language. > It obviously avoids the distasteful duplication of "data = my_file.read(1024)". You're right, it's the way it has to be done, but I personally find it awful code. "while True" is a do-forever, so that's what you read first, but that's not really what we want to write. Then we read, OK, but then we break out of the forever loop, then we don't, and do something with the data we read. It's a mess. What I'd like to be able to write is something like this: while my_file.has_more_data(): do_something_with_data(my_file.read(1024)) For instance: for line in open(filename): do_something_with_data(line) Which, in its non-line form, is pretty much what Josiah suggested. +1 for adding "blocked_reader" as a static method on the "file" class, or perhaps one of the IOStream ABC classes. Bill From bronger at physik.rwth-aachen.de Thu Jul 3 19:11:02 2008 From: bronger at physik.rwth-aachen.de (Torsten Bronger) Date: Thu, 03 Jul 2008 19:11:02 +0200 Subject: [Python-ideas] "While" suggestion References: <486CDCF5.6080805@korokithakis.net> Message-ID: <873amqevvd.fsf@physik.rwth-aachen.de> Hall?chen! Facundo Batista writes: > 2008/7/3 Stavros Korokithakis > : > >> while my_file.read(1024) as data: >> do_something(data) > > Python explicitly disallows inline assignment ("while > a=myfile.read():") because of the error propensity when confusing > it with the comparation ("=="). But here we're gaining the same > advantage, without that risk. > > So, taking into account that... > > a) We already have "as" as an statement. > > b) We already use "as" as an assignment [1] > > c) This will allow more concise and intuitive code > > ... I'm definitely +1 to this proposition. I don't like it. Taken as an English expression, it suggests something misleading. I looked at my own code (not much; 15.000 lines) and found three "while True", and none of them could be expressed with "while ... as ...". It is not worth it in my opinion. However, it *is* an issue in Python. The almost official repeat...until is "while True:", and I got accustomed to reading it as a repeat...until. But actually, it is even more flexible since it is the most general loop at all. Granted that "while True" is not eye-pleasant. Maybe we could introduce the idion "while not break:". ;-) Tsch?, Torsten. -- Torsten Bronger, aquisgrana, europa vetus Jabber ID: torsten.bronger at jabber.rwth-aachen.de From brett at python.org Thu Jul 3 19:46:05 2008 From: brett at python.org (Brett Cannon) Date: Thu, 3 Jul 2008 10:46:05 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <47c890dc0807030814v55449235ucc6d08d6249216f7@mail.gmail.com> <486CEE63.8050800@korokithakis.net> <057E8E37-60FE-4B1A-B653-AF953CCDD574@acm.org> Message-ID: On Thu, Jul 3, 2008 at 8:45 AM, Facundo Batista wrote: > 2008/7/3 Fred Drake : > >> The "while as :" for has a certain level of attraction, because >> it does deal very well with a very common case, but I don't know that it >> would make that much difference in my code. > > Note that what I like in it is *not* that it solves a lot of cases, > but that it makes the syntax more coherent, and solves a common case > in the way, :) > Typically a good way of making a point that a new syntax proposal will have impact is to find as many places as possible in the standard library where the code was improved by the change. If a bunch of places become easier to read then that will squash the need for it solve a ton of different cases because it solves a very common case instead. -Brett From fdrake at acm.org Thu Jul 3 19:46:20 2008 From: fdrake at acm.org (Fred Drake) Date: Thu, 3 Jul 2008 13:46:20 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: <873amqevvd.fsf@physik.rwth-aachen.de> References: <486CDCF5.6080805@korokithakis.net> <873amqevvd.fsf@physik.rwth-aachen.de> Message-ID: <182246F1-AC87-4DF3-B89E-2042E3955A1E@acm.org> On Jul 3, 2008, at 1:11 PM, Torsten Bronger wrote: > Granted that "while True" is not eye-pleasant. Maybe we could > introduce the idion "while not break:". ;-) A little tongue-in-cheek, but works today: # in some devious place: import __builtin__ __builtin__.broken = False # in application code: while not broken: break_something() -Fred -- Fred Drake From leif.walsh at gmail.com Thu Jul 3 19:57:39 2008 From: leif.walsh at gmail.com (Leif Walsh) Date: Thu, 3 Jul 2008 10:57:39 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <873amqevvd.fsf@physik.rwth-aachen.de> References: <486CDCF5.6080805@korokithakis.net> <873amqevvd.fsf@physik.rwth-aachen.de> Message-ID: I am against while...as syntax for a reason given above (doesn't map to an english statement nearly as well as with...as does). Besides, you can write much clearer code by making yourself a generator somewhere else that does the nasty bits, and then using a for loop to actually consume the data, like you should: def kilogenerator(file): while True: try: yield file.read(1024) except EOFError: # or whatever return for kilo in kilogenerator(myfile): process(kilo) -- Cheers, Leif From bruce at leapyear.org Thu Jul 3 20:04:50 2008 From: bruce at leapyear.org (Bruce Leban) Date: Thu, 3 Jul 2008 11:04:50 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CDCF5.6080805@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> Message-ID: One thing I don't like about using "as" here is that with has very different semantics for that assignment than while does. I'd rather have: while data in [[my_file.read(1024)]]: where [[...]] is a shorthand for iter(lambda: ..., None) since at least the concept of taking an expression and turning it into an iterator is fairly general. OK, that's pretty ugly so maybe I wouldn't want it. :-) If you add this to while, you're going to want this in "if" and there are lot of other cases like: while (read_a_number() as data) > 0: I'd rather see something along the lines of PEP 315. --- Bruce On Thu, Jul 3, 2008 at 7:06 AM, Stavros Korokithakis < stavros at korokithakis.net> wrote: > Hello all, > I have noticed that sometimes "while" loops produce "unpythonic" patterns, > such as the following: > > data = my_file.read(1024) > while data: > do_something(data) > data = my_file.read(1024) > > The assignment is repeated, which is less than optimal. Since we don't have > a while statement that does the check in the end, would it not be better if > the syntax of while could be amended to include something like this (in the > spirit of the new "with" keyword)?: > > while my_file.read(1024) as data: > do_something(data) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnodel at googlemail.com Thu Jul 3 21:09:00 2008 From: arnodel at googlemail.com (Arnaud Delobelle) Date: Thu, 3 Jul 2008 20:09:00 +0100 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> Message-ID: <9bfc700a0807031209m73547e5eyf1b09f0f6894cfe5@mail.gmail.com> 2008/7/3 Facundo Batista : > 2008/7/3 Stavros Korokithakis : > >> while my_file.read(1024) as data: >> do_something(data) > > Python explicitly disallows inline assignment ("while > a=myfile.read():") because of the error propensity when confusing it > with the comparation ("=="). But here we're gaining the same > advantage, without that risk. For me, the main advantage of binding being provided by a statement rather than an expression is not that it eliminates confusion with test for equality. The main advantage is that it prevents *sneaky* (re)binding. You can't bind a name from within an expression, it has to be clearly advertised: foo = 'new value' When I'm scanning code later I'm not going to miss these. IMHO, giving that up would be a mistake. -- Arnaud From tjreedy at udel.edu Thu Jul 3 21:31:32 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 03 Jul 2008 15:31:32 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com> Message-ID: Facundo Batista wrote: > 2008/7/3 George Sakkis : > >> There is already an idiom for this, although admittedly not obvious or >> well-known: >> >> for data in iter(lambda: my_file.read(1024), ''): >> do_something(data) >> >> or in 2.5+: >> >> from functools import partial >> for data in iter(partial(my_file.read,1024), ''): >> do_something(data) > > Yes, but note that these feels like workarounds. I disagree, and will explain. To me, iterators are one of the great unifying concept of Python, and for statements are the canonical way to iterate. The end of a sequence, if there is one, can be signaled by any sentinel object or exception. The iterator protocol abstracts away the different possible signals and replaces them all with one exception used just for this purpose and which therefore cannot conflict with any object in the sequence nor be confused with any unexpected exception raised by their production. When used in a for statement, it separates the concern of detecting the end of the sequence from the concern of processing the items of the sequence. So, in this view, making a block-reading-and-yielding iterator, if one does not exist out of the box, is the proper thing to do for processing blocks. While statements are for all other loops for which for statements do not work (including, sometimes, the code buried within a generator function). The suggestion of 'while as ' proposes a new 'expression-iterator' protocol for expression-produced sequences of non-null objects terminated by *any* null object. -1 from me, because a) It unnecessarily duplicates one of Python's gems. b) The use of *all* null objects as sentinels is almost never what one wants in any particular situation. If it is, it is easy enough to write def non_nulls(f): while True: o = f() if o: yield o else: raise StopIteraton # or just break c) Using all nulls as sentinels restricts the sequence more than using just one. It is also bug bait. Suppose f returns next_number or None. A slightly naive or careless programmer writes 'while f as x: ...'. At some point, f returns 0. Whoops. It is better to be specific and only terminate on the intended terminator. For this example, iter(f,None), or iter(f,'' as George suggested for the OP's use case. Careful programming is *not* a workaround. Terry Jan Reedy From steven.bethard at gmail.com Thu Jul 3 22:15:04 2008 From: steven.bethard at gmail.com (Steven Bethard) Date: Thu, 3 Jul 2008 14:15:04 -0600 Subject: [Python-ideas] "While" suggestion In-Reply-To: <873amqevvd.fsf@physik.rwth-aachen.de> References: <486CDCF5.6080805@korokithakis.net> <873amqevvd.fsf@physik.rwth-aachen.de> Message-ID: On Thu, Jul 3, 2008 at 11:11 AM, Torsten Bronger wrote: >> 2008/7/3 Stavros Korokithakis >> : >> >>> while my_file.read(1024) as data: >>> do_something(data) > > I don't like it. Taken as an English expression, it suggests > something misleading. I looked at my own code (not much; 15.000 > lines) and found three "while True", and none of them could be > expressed with "while ... as ...". It is not worth it in my > opinion. I had similar results. Around 10 "while True" constructs, and none of them would have worked with "while ... as ..." -1 for me. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From stavros at korokithakis.net Thu Jul 3 22:22:56 2008 From: stavros at korokithakis.net (Stavros Korokithakis) Date: Thu, 03 Jul 2008 23:22:56 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <873amqevvd.fsf@physik.rwth-aachen.de> Message-ID: <486D3520.9010406@korokithakis.net> I don't know where this "while True" concept snuck in, the proposal isn't supposed to replace those, it's supposed to replace this: while " Stavros Steven Bethard wrote: > On Thu, Jul 3, 2008 at 11:11 AM, Torsten Bronger > wrote: >>> 2008/7/3 Stavros Korokithakis >>> : >>> >>>> while my_file.read(1024) as data: >>>> do_something(data) >> I don't like it. Taken as an English expression, it suggests >> something misleading. I looked at my own code (not much; 15.000 >> lines) and found three "while True", and none of them could be >> expressed with "while ... as ...". It is not worth it in my >> opinion. > > I had similar results. Around 10 "while True" constructs, and none of > them would have worked with "while ... as ..." > > -1 for me. > > Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: stavros.vcf Type: text/x-vcard Size: 143 bytes Desc: not available URL: From steven.bethard at gmail.com Thu Jul 3 22:29:06 2008 From: steven.bethard at gmail.com (Steven Bethard) Date: Thu, 3 Jul 2008 14:29:06 -0600 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486D3520.9010406@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> <873amqevvd.fsf@physik.rwth-aachen.de> <486D3520.9010406@korokithakis.net> Message-ID: On Thu, Jul 3, 2008 at 2:22 PM, Stavros Korokithakis wrote: > I don't know where this "while True" concept snuck in, the proposal isn't > supposed to replace those, it's supposed to replace this: > > > while " > > The "while True" concept "snuck in" because many of us write this idiom as:: while True: if not : break Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From cvrebert at gmail.com Thu Jul 3 22:30:42 2008 From: cvrebert at gmail.com (Chris Rebert) Date: Thu, 3 Jul 2008 13:30:42 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486D3520.9010406@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> <873amqevvd.fsf@physik.rwth-aachen.de> <486D3520.9010406@korokithakis.net> Message-ID: <47c890dc0807031330j61954ed5g12531a5c18078bc9@mail.gmail.com> On Thu, Jul 3, 2008 at 1:22 PM, Stavros Korokithakis wrote: > I don't know where this "while True" concept snuck in, the proposal isn't > supposed to replace those, it's supposed to replace this: > > > while " > > And "while True" is the currently accepted idiom to replace that, which possibly makes "while as" unnecessary. while True: if not : break Note that is no longer repeated. - Chris > > Stavros > > Steven Bethard wrote: >> >> On Thu, Jul 3, 2008 at 11:11 AM, Torsten Bronger >> wrote: >>>> >>>> 2008/7/3 Stavros Korokithakis >>>> : >>>> >>>>> while my_file.read(1024) as data: >>>>> do_something(data) >>> >>> I don't like it. Taken as an English expression, it suggests >>> something misleading. I looked at my own code (not much; 15.000 >>> lines) and found three "while True", and none of them could be >>> expressed with "while ... as ...". It is not worth it in my >>> opinion. >> >> I had similar results. Around 10 "while True" constructs, and none of >> them would have worked with "while ... as ..." >> >> -1 for me. >> >> Steve > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > > From bruce at leapyear.org Thu Jul 3 22:34:15 2008 From: bruce at leapyear.org (Bruce Leban) Date: Thu, 3 Jul 2008 13:34:15 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486D3520.9010406@korokithakis.net> References: <486CDCF5.6080805@korokithakis.net> <873amqevvd.fsf@physik.rwth-aachen.de> <486D3520.9010406@korokithakis.net> Message-ID: And it doesn't do that! It only replaces that when is a simple assignment. PEP 315 suggested: do: while : which does cover the general scenario. On Thu, Jul 3, 2008 at 1:22 PM, Stavros Korokithakis < stavros at korokithakis.net> wrote: > I don't know where this "while True" concept snuck in, the proposal isn't > supposed to replace those, it's supposed to replace this: > > > while " > > > > Stavros > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cvrebert at gmail.com Thu Jul 3 22:39:25 2008 From: cvrebert at gmail.com (Chris Rebert) Date: Thu, 3 Jul 2008 13:39:25 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <873amqevvd.fsf@physik.rwth-aachen.de> <486D3520.9010406@korokithakis.net> Message-ID: <47c890dc0807031339t7027dd9v4329b6cd32d2bfcf@mail.gmail.com> On Thu, Jul 3, 2008 at 1:34 PM, Bruce Leban wrote: > And it doesn't do that! It only replaces that when is a simple > assignment. > > PEP 315 suggested: > > do: > > while : > > > which does cover the general scenario. The "while as" proposal is even less general. It only covers single-statement assignment s. And do multiline s really come up that often? Not in my experience at least. - Chris > > > On Thu, Jul 3, 2008 at 1:22 PM, Stavros Korokithakis > wrote: >> >> I don't know where this "while True" concept snuck in, the proposal isn't >> supposed to replace those, it's supposed to replace this: >> >> >> while " >> >> >> >> Stavros > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > > From bjourne at gmail.com Thu Jul 3 22:53:59 2008 From: bjourne at gmail.com (=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=) Date: Thu, 3 Jul 2008 20:53:59 +0000 Subject: [Python-ideas] "While" suggestion In-Reply-To: <486CE904.2040403@vector-seven.com> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> Message-ID: <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> On Thu, Jul 3, 2008 at 2:58 PM, Thomas Lee wrote: > Stavros Korokithakis wrote: >> >> I don't think they do, if I'm not mistaken the only way is to call read() >> and see if it returns the empty string. I agree that this would be better, >> but the use case I mentioned is not the only one this would be useful in... >> Unfortunately I can't think of any right now, > > :) >> >> but there have been a few times when I had to initialise things outside >> the loop and it always strikes me as ugly. >> > Well that depends, on the situation really. The only use case I can think of > is exactly the one you mentioned. And since you can't think of any other > scenarios where such a thing might be handy, I've got no better suggestion > to offer. > > If you can conjure up another scenario, post it back here and we'll see if > we can generalize the pattern a little. Randomly choose a number 0-100 that is not already picked: # Current Python number = random.randint(1, 100) while number in picked_numbers: number = random.randint(1, 100) # Do-Until do: number = random.randint(1, 100) until number not in picked_numbers # While-As Doesn't seem to be doable. Maybe with the proposed syntax either: while random.randint(1, 100) as number in picked_numbers: pass or while random.randint(1, 100) in picked_numbers as number: pass would work. But it doesn't look pretty anymore. I would definitely prefer a do-until or do-while construct instead. -- mvh Bj?rn From cvrebert at gmail.com Thu Jul 3 23:01:35 2008 From: cvrebert at gmail.com (Chris Rebert) Date: Thu, 3 Jul 2008 14:01:35 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> Message-ID: <47c890dc0807031401q535d6cb0tb1567abd99116f65@mail.gmail.com> Purely for the sake of completeness: #while True idiom (current Python) while True: number = random.randint(1, 100) if number not in picked_numbers: break - Chris On Thu, Jul 3, 2008 at 1:53 PM, BJ?rn Lindqvist wrote: > On Thu, Jul 3, 2008 at 2:58 PM, Thomas Lee wrote: >> Stavros Korokithakis wrote: >>> >>> I don't think they do, if I'm not mistaken the only way is to call read() >>> and see if it returns the empty string. I agree that this would be better, >>> but the use case I mentioned is not the only one this would be useful in... >>> Unfortunately I can't think of any right now, >> >> :) >>> >>> but there have been a few times when I had to initialise things outside >>> the loop and it always strikes me as ugly. >>> >> Well that depends, on the situation really. The only use case I can think of >> is exactly the one you mentioned. And since you can't think of any other >> scenarios where such a thing might be handy, I've got no better suggestion >> to offer. >> >> If you can conjure up another scenario, post it back here and we'll see if >> we can generalize the pattern a little. > > Randomly choose a number 0-100 that is not already picked: > > # Current Python > number = random.randint(1, 100) > while number in picked_numbers: > number = random.randint(1, 100) > > # Do-Until > do: > number = random.randint(1, 100) > until number not in picked_numbers > > # While-As > Doesn't seem to be doable. Maybe with the proposed syntax either: > > while random.randint(1, 100) as number in picked_numbers: > pass > > or > > while random.randint(1, 100) in picked_numbers as number: > pass > > would work. But it doesn't look pretty anymore. I would definitely > prefer a do-until or do-while construct instead. > > > -- > mvh Bj?rn > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > From arnodel at googlemail.com Thu Jul 3 23:20:19 2008 From: arnodel at googlemail.com (Arnaud Delobelle) Date: Thu, 3 Jul 2008 22:20:19 +0100 Subject: [Python-ideas] "While" suggestion In-Reply-To: <47c890dc0807031401q535d6cb0tb1567abd99116f65@mail.gmail.com> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <47c890dc0807031401q535d6cb0tb1567abd99116f65@mail.gmail.com> Message-ID: <1672E7C6-A207-4001-A9B0-393C533D23ED@googlemail.com> On 3 Jul 2008, at 22:01, Chris Rebert wrote: > Purely for the sake of completeness: > > #while True idiom (current Python) > while True: > number = random.randint(1, 100) > if number not in picked_numbers: > break And even more completeness :) #iter idiom def rand100(): random.randint(1, 100) for number in iter(rand100, None): if number not in picked_numbers: break -- Arnaud From bjourne at gmail.com Fri Jul 4 02:12:25 2008 From: bjourne at gmail.com (=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=) Date: Fri, 4 Jul 2008 00:12:25 +0000 Subject: [Python-ideas] "While" suggestion In-Reply-To: <20080703173807.378af74a@bhuda.mired.org> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <47c890dc0807031401q535d6cb0tb1567abd99116f65@mail.gmail.com> <20080703173807.378af74a@bhuda.mired.org> Message-ID: <740c3aec0807031712n30679d03ve0e073a791bd2497@mail.gmail.com> On Thu, Jul 3, 2008 at 9:38 PM, Mike Meyer wrote: >> #while True idiom (current Python) >> while True: >> number = random.randint(1, 100) >> if number not in picked_numbers: >> break > > I don't believe that actually qualifies as "current python", any more > than the other current alternative: > > # duplicate setup (current Python) > number = random.randint(1, 100) > while number in picked_numbers: > number = random.randint(1, 100) > > does. > > Both bits of code smell. One has the duplicated line; one has a test > of a constant and a block exiting from the middle, all of which make > the code slightly less clear. Yup. Non-for loops just aren't very strong in Python. > I tend to write either one, depending on what the duplicated code > looks like. For this case, I actually prefer the latter. On the other > hand, I'd probably write this one using a *third* alternative idiom: > > # Picked initial value (current Python) > number = picked_numbers[0] > while number in picked_numbers: > number = random.randint(1, 100) I didn't say that the picked_numbers list had to be non-empty so you lose. :) -- mvh Bj?rn From python at rcn.com Fri Jul 4 04:58:27 2008 From: python at rcn.com (Raymond Hettinger) Date: Thu, 3 Jul 2008 19:58:27 -0700 Subject: [Python-ideas] "While" suggestion References: <486CDCF5.6080805@korokithakis.net><486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net><486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> Message-ID: From: "BJ?rn Lindqvist" > I would definitely prefer a do-until or do-while construct instead. I co-authored a PEP for a do-while construct and it died solely because we couldn't find a good pythonic syntax. The proposed while-as construct will neatly solve some of the use cases -- the rest will have to live with what we've got. Raymond From fdrake at acm.org Fri Jul 4 05:21:12 2008 From: fdrake at acm.org (Fred Drake) Date: Thu, 3 Jul 2008 23:21:12 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net><486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net><486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> Message-ID: <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> On Jul 3, 2008, at 10:58 PM, Raymond Hettinger wrote: > I co-authored a PEP for a do-while construct and it died solely > because we couldn't find a good pythonic syntax. The proposed while- > as construct will neatly solve some of the use cases -- the rest > will have to live with what we've got. I actually like the "do: ... while : ..." syntax better. -Fred -- Fred Drake From guido at python.org Fri Jul 4 05:33:22 2008 From: guido at python.org (Guido van Rossum) Date: Thu, 3 Jul 2008 20:33:22 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> Message-ID: On Thu, Jul 3, 2008 at 8:21 PM, Fred Drake wrote: > On Jul 3, 2008, at 10:58 PM, Raymond Hettinger wrote: >> >> I co-authored a PEP for a do-while construct and it died solely because we >> couldn't find a good pythonic syntax. The proposed while-as construct will >> neatly solve some of the use cases -- the rest will have to live with what >> we've got. > > I actually like the "do: ... while : ..." syntax better. Same here. The while ... as ... syntax introduces a special case that doesn't handle enough cases to be worth the cost of a special case. Zen of Python: "Special cases aren't special enough to break the rules." To summarize why while...as... doesn't handle enough cases: it only works if the can be expressed a single assignment and the value assigned is also the value to be tested. Like it or not, many uses of assignment expressions in C take forms like these: if ((x = ) > 0 && (y = ) < 0) { ... } while ((p = foo()) != NULL && p->bar) { ... } If we were to add "while x as y:" in 3.1, I'm sure we'd get pressure to add "if x as y:" in 3.2, and then "if (x as y) and (p as q):" in 3.3, and so on. Assignment-in-test: Just Say No. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From greg.ewing at canterbury.ac.nz Sat Jul 5 03:30:14 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sat, 05 Jul 2008 13:30:14 +1200 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> Message-ID: <486ECEA6.8030103@canterbury.ac.nz> Guido van Rossum wrote: > If we were to add "while x as y:" in 3.1, I'm sure we'd get pressure > to add "if x as y:" in 3.2, and then "if (x as y) and (p as q):" in > 3.3, and so on. All that could be short-circuited by making 'expr as name' a valid expression in general from the outset. However, that would make 'with x as y' inconsistent, because it doesn't bind the value of x to y, but rather the result of x.__enter__(). (Often it's the same thing, but it doesn't have to be.) Then there's the new form of except clause that uses 'as' in another slightly different way. So while this proposal might at first appear to make things more consistent, it actually doesn't. The way things are, each use of 'as' is unique, so it can be regarded as consistently inconsistent. Introducing a general 'expr as name' construct would set up an expectation that 'as' is simply a binding operator, and then the existing uses would stick out more by being inconsistently inconsistent. :-) -- Greg From rnd at onego.ru Sat Jul 5 17:45:20 2008 From: rnd at onego.ru (Roman Susi) Date: Sat, 05 Jul 2008 18:45:20 +0300 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea Message-ID: <486F9710.6060602@onego.ru> hi! I am sure that Python interactive interpreter is a good tool. Before it were simple to print something with print. Now extra ( and ) are needed and also extra caution. Is it possible to have some simplified "print" in the interactive interpreter? IMHO, Basic's "?" is quite a good candidate. Maybe, it should not even be Python syntax but Python interactive shell feature. cf: >>> print(functools.wraps.__doc__) and >>> ? functools.wraps.__doc__ Also, some discussions about http://bugs.python.org/issue449227 (can't recall where they were, maybe private) indicate that maybe some kind of Python shell API could be interesting to facilitate Python interpreter's interaction with shells and provide better, more dynamic, experience to the shells' users (e.g. readline-like features, inline helps and hints, etc). With the API it will be easier for "vendors" to come up with CLUI/GUI/whatever shells. Shells will be thus decoupled from the interpreter itself. (WSGI is pretty similar in intention to abstract web service interaction, maybe the one I suggest may be called Rich Interpreter Shell Gateway Interface (RISGI) or something like that). The idea is quite raw, maybe not even pre-PEPable yet, because I am not really shell developer. It also differs from the way Python gets programmatically embed into something because the interface is really meant ot be like Python interpreter's "telnet" or "X", for humans. There could be addons to the shell protocol use (debugger or profiler subshells, datastructure/class/module browser subshell/subprotocol, help subshells). Special case shells (using same protocol) may be used, eg, for mobile phone Python. To put these topics in two: "standard" Python shell may provide keystroke shortcuts for some useful cases (like, today's shell is having underscore to mean most recently calculated expression value). So, "?" will not be part of the syntax but a shell's shortcut. I think that such shell protocol is quite unique for the programming languages and may be real breakthrough in interactive shell field and/or even whole CLUI. -Roman From santagada at gmail.com Sat Jul 5 18:09:06 2008 From: santagada at gmail.com (Leonardo Santagada) Date: Sat, 5 Jul 2008 13:09:06 -0300 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea In-Reply-To: <486F9710.6060602@onego.ru> References: <486F9710.6060602@onego.ru> Message-ID: On 05/07/2008, at 12:45, Roman Susi wrote: > cf: > > >>>> print(functools.wraps.__doc__) > > and > >>>> ? functools.wraps.__doc__ in ipython you have: In [1]: functools.wraps? that will print the docstring and if you do ?? it will print the source code (or at least try to). Maybe one idea would be to list all different python interactive interpreters out there and try to come up with a pep describing improvements to the current python interpreter. Maybe list everything that could be done without readline (or any other similar library) and what depend on complex line editing facilities so there could become a option to the interpreter. -- Leonardo Santagada From tjreedy at udel.edu Sat Jul 5 23:49:39 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 05 Jul 2008 17:49:39 -0400 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea In-Reply-To: <486F9710.6060602@onego.ru> References: <486F9710.6060602@onego.ru> Message-ID: Roman Susi wrote: > I am sure that Python interactive interpreter is a good tool. > > Before it were simple to print something with print. It always was and is easier to leave print off and just type the expression ;-) > Is it possible to have some simplified "print" in the interactive > interpreter? We already and always have had such: just type the expression From greg.ewing at canterbury.ac.nz Sun Jul 6 02:22:17 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Sun, 06 Jul 2008 12:22:17 +1200 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea In-Reply-To: <486F9710.6060602@onego.ru> References: <486F9710.6060602@onego.ru> Message-ID: <48701039.8000805@canterbury.ac.nz> Roman Susi wrote: > Before it were simple to print something with print. Now extra ( and ) > are needed and also extra caution. How often does one really need to use print in the interactive shell, given than you can just type an expression and get the repr of the result? -- Greg From aahz at pythoncraft.com Sun Jul 6 06:25:43 2008 From: aahz at pythoncraft.com (Aahz) Date: Sat, 5 Jul 2008 21:25:43 -0700 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea In-Reply-To: <48701039.8000805@canterbury.ac.nz> References: <486F9710.6060602@onego.ru> <48701039.8000805@canterbury.ac.nz> Message-ID: <20080706042543.GA7809@panix.com> On Sun, Jul 06, 2008, Greg Ewing wrote: > Roman Susi wrote: >> >>Before it were simple to print something with print. Now extra ( and ) >>are needed and also extra caution. > > How often does one really need to use print in the interactive > shell, given than you can just type an expression and get > the repr of the result? Actually, I use it frequently because typing "print EXPR" is easier than "str(EXPR)", and often enough the difference between str() and repr() is useful (especially in doctests). I guess when I upgrade to 3.0, I'm likely to switch to str() instead of print. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ "as long as we like the same operating system, things are cool." --piranha From rnd at onego.ru Sun Jul 6 09:02:42 2008 From: rnd at onego.ru (Roman Susi) Date: Sun, 06 Jul 2008 10:02:42 +0300 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea In-Reply-To: References: <486F9710.6060602@onego.ru> Message-ID: <48706E12.3010702@onego.ru> Terry Reedy wrote: > > > Roman Susi wrote: > >> I am sure that Python interactive interpreter is a good tool. >> >> Before it were simple to print something with print. > > It always was and is easier to leave print off and just type the > expression ;-) It gives you repr and its not always useful, e.g. >>> s u'\u042d\u0442\u043e \u043e\u0447\u0435\u043d\u044c \u0445\u043e\u0440\u043e\u0448\u0430\u044f \u0441\u0442\u0440\u043e\u043a\u0430' > > Is it possible to have some simplified "print" in the interactive >> interpreter? > > We already and always have had such: just type the expression Well, my point which was completely ignored (maybe due to too lengthy explanation) is that the shell could be smarter beyond readline and that shell to interpreter protocol may be a well-defined API, specifying "main course" (Python commands) as well introspection features. Regards, Roman From rnd at onego.ru Sun Jul 6 11:41:03 2008 From: rnd at onego.ru (Roman Susi) Date: Sun, 06 Jul 2008 12:41:03 +0300 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea In-Reply-To: References: <486F9710.6060602@onego.ru> Message-ID: <4870932F.2080701@onego.ru> Leonardo Santagada wrote: > > On 05/07/2008, at 12:45, Roman Susi wrote: >> cf: >> >> >>>>> print(functools.wraps.__doc__) >> >> and >> >>>>> ? functools.wraps.__doc__ > > > in ipython you have: Thanks! ipython is very nice. (I always thought it's something about .net and thus ignored it :-) -Roman > > In [1]: functools.wraps? > > that will print the docstring and if you do ?? it will print the source > code (or at least try to). Maybe one idea would be to list all different > python interactive interpreters out there and try to come up with a pep > describing improvements to the current python interpreter. Maybe list > everything that could be done without readline (or any other similar > library) and what depend on complex line editing facilities so there > could become a option to the interpreter. > > -- > Leonardo Santagada > From phd at phd.pp.ru Sun Jul 6 16:31:47 2008 From: phd at phd.pp.ru (Oleg Broytmann) Date: Sun, 6 Jul 2008 18:31:47 +0400 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea In-Reply-To: <48701039.8000805@canterbury.ac.nz> References: <486F9710.6060602@onego.ru> <48701039.8000805@canterbury.ac.nz> Message-ID: <20080706143147.GA5218@phd.pp.ru> On Sun, Jul 06, 2008 at 12:22:17PM +1200, Greg Ewing wrote: > Roman Susi wrote: > > >Before it were simple to print something with print. Now extra ( and ) > >are needed and also extra caution. > > How often does one really need to use print in the interactive > shell, given than you can just type an expression and get > the repr of the result? It is is not always repr(): $ python Python 2.5 (release25-maint, Dec 9 2006, 14:35:53) [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print '' or None None >>> '' or None >>> print ['????'] ['\xd4\xc5\xd3\xd4'] >>> ['????'] ['????'] Note the difference. Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd at phd.pp.ru Programmers don't die, they just GOSUB without RETURN. From rnd at onego.ru Sun Jul 6 17:49:59 2008 From: rnd at onego.ru (Roman Susi) Date: Sun, 06 Jul 2008 18:49:59 +0300 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea In-Reply-To: <20080706143147.GA5218@phd.pp.ru> References: <486F9710.6060602@onego.ru> <48701039.8000805@canterbury.ac.nz> <20080706143147.GA5218@phd.pp.ru> Message-ID: <4870E9A7.7070403@onego.ru> Oleg Broytmann wrote: > On Sun, Jul 06, 2008 at 12:22:17PM +1200, Greg Ewing wrote: >> Roman Susi wrote: >> >>> Before it were simple to print something with print. Now extra ( and ) >>> are needed and also extra caution. >> How often does one really need to use print in the interactive >> shell, given than you can just type an expression and get >> the repr of the result? > > It is is not always repr(): > > $ python > Python 2.5 (release25-maint, Dec 9 2006, 14:35:53) > [GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-20)] on linux2 > Type "help", "copyright", "credits" or "license" for more information. >>>> print '' or None > None >>>> '' or None >>>> print ['????'] > ['\xd4\xc5\xd3\xd4'] >>>> ['????'] > ['????'] Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Readline loaded. History loaded. >>> ['????'] ['\xd1\x82\xd0\xb5\xd1\x81\xd1\x82'] >>> print ['????'] ['\xd1\x82\xd0\xb5\xd1\x81\xd1\x82'] > Note the difference. Can't see any difference in the latter example (matter of encodings, I guess), however, None is treated specially, it is true. At any rate, repr or not, its more typing to get the "nicer" result. My point is that the shell could be more sophisticated. > Oleg. -Roman From guido at python.org Mon Jul 7 19:05:25 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 7 Jul 2008 10:05:25 -0700 Subject: [Python-ideas] print in the interactive interpreter? plus shell API idea In-Reply-To: <48706E12.3010702@onego.ru> References: <486F9710.6060602@onego.ru> <48706E12.3010702@onego.ru> Message-ID: On Sun, Jul 6, 2008 at 12:02 AM, Roman Susi wrote: > Well, my point which was completely ignored (maybe due to too lengthy > explanation) is that the shell could be smarter beyond readline and that > shell to interpreter protocol may be a well-defined API, specifying > "main course" (Python commands) as well introspection features. I hear you, and I reject the feature request. This is a good area for 3rd party development -- e.g. ipython is currently the market leader. However, for the built-in interactive command line, I want there to be as little as possible difference with the language as accepted in modules. Any time you have a shortcut that works in interactive mode, somebody just learning the language is going to try it in a module and be very confused that it doesn't work. Clearly line editing operations are exempt from this argumentation, but I strongly dislike adding shortcuts like '?' for this reason. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From talin at acm.org Tue Jul 8 04:10:49 2008 From: talin at acm.org (Talin) Date: Mon, 07 Jul 2008 19:10:49 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> Message-ID: <4872CCA9.1040908@acm.org> Guido van Rossum wrote: > On Thu, Jul 3, 2008 at 8:21 PM, Fred Drake wrote: >> On Jul 3, 2008, at 10:58 PM, Raymond Hettinger wrote: >>> I co-authored a PEP for a do-while construct and it died solely because we >>> couldn't find a good pythonic syntax. The proposed while-as construct will >>> neatly solve some of the use cases -- the rest will have to live with what >>> we've got. >> I actually like the "do: ... while : ..." syntax better. > > Same here. The while ... as ... syntax introduces a special case that > doesn't handle enough cases to be worth the cost of a special case. > Zen of Python: "Special cases aren't special enough to break the > rules." > > To summarize why while...as... doesn't handle enough cases: it only > works if the can be expressed a single assignment and the > value assigned is also the value to be tested. Like it or not, many > uses of assignment expressions in C take forms like these: I'm actually more interested in the "as" clause being added to "if" rather than "while". The specific use case I am thinking is matching regular expressions, like so: def match_token(s): # Assume we have regex's precompiled for the various tokens: if re_comment.match(s) as m: # Do something with m process(TOK_COMMENT, m.group(1)) elif re_ident.match(s) as m: # Do something with m process(TOK_IDENT, m.group(1)) elif re_integer.match(s) as m: # Do something with m process(TOK_INT, m.group(1)) elif re_float.match(s) as m: # Do something with m process(TOK_COMMENT, m.group(1)) elif re_string.match(s) as m: # Do something with m process(TOK_STRING, m.group(1)) else: raise InvalidTokenError(s) In other words, the general design pattern is one where you have a series of tests, where each test can return either None, or an object that you want to examine further. Of course, if it's just a single if-statement, it's easy enough to assign the variable in one statement and test in the next. There are a number of workarounds, of course - put the tests in a function and use return instead of elif; Use 'else' instead of elif and put the subsequent 'if' in the else block (and deal with indentation crawl) and so on. So it's not a huge deal, I'm just pointing out one possible use case where it might make the code a bit prettier. (Also, there's a much faster way to do the above example, which is to smush all of the patterns into a single massive regex, and then check the last group index of the match object to see which one matched.) -- Talin From guido at python.org Tue Jul 8 06:08:04 2008 From: guido at python.org (Guido van Rossum) Date: Mon, 7 Jul 2008 21:08:04 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <4872CCA9.1040908@acm.org> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> Message-ID: On Mon, Jul 7, 2008 at 7:10 PM, Talin wrote: > I'm actually more interested in the "as" clause being added to "if" rather > than "while". Thanks for the support. :-) The more examples we get suggesting that this might also come in handy in other contexts the more ammo I have against the request to add it *just* to the while loop. And adding it everywhere is not an option, as has been explained previously. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From tjreedy at udel.edu Tue Jul 8 20:16:11 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 08 Jul 2008 14:16:11 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: <4872CCA9.1040908@acm.org> References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> Message-ID: Talin wrote: > I'm actually more interested in the "as" clause being added to "if" > rather than "while". The specific use case I am thinking is matching > regular expressions, like so: > > def match_token(s): > # Assume we have regex's precompiled for the various tokens: > if re_comment.match(s) as m: > # Do something with m > process(TOK_COMMENT, m.group(1)) > elif re_ident.match(s) as m: > # Do something with m > process(TOK_IDENT, m.group(1)) > elif re_integer.match(s) as m: > # Do something with m > process(TOK_INT, m.group(1)) > elif re_float.match(s) as m: > # Do something with m > process(TOK_COMMENT, m.group(1)) > elif re_string.match(s) as m: > # Do something with m > process(TOK_STRING, m.group(1)) > else: > raise InvalidTokenError(s) > > In other words, the general design pattern is one where you have a > series of tests, where each test can return either None, or an object > that you want to examine further. One of the things I do not like above is the repetition of the assignment target, and statement ends, where it is a little hard to see if it is spelled the same each time. I think it would be more productive to work on adding to the stdlib a standardized store-and-test class -- something like what others have posted on c.l.p. In the below, I factored out the null test value(s) from the repeated if tests and added it to the pocket instance as a nulls test attribute. def pocket(): def __init__(self, nulls): if type(nul;s) != tuple or nulls == (): nulls = (nulls,) self.nulls = nulls def __call__(self, value): self.value = value return self def __bool__(self) return not (self.value in self.nulls) then def match_token(s): # Assume we have regex's precompiled for the various tokens: p = pocket(None) # None from above, I don't know match return if p(re_comment.match(s)): # Do something with p.value process(TOK_COMMENT, p.value.group(1)) elif p(re_ident.match(s)): # Do something with p.value process(TOK_IDENT, p.value.group(1)) elif p(re_integer.match(s)): # etc Pocket could be used for the while case, but I will not show that because I strongly feel 'for item in iteratot' is the proper idiom. Your specific example is so regular that it also could be written (better in my opinion) as a for loop by separating what varies from what does not: match_tok = ( (re_comment, TOK_COMMENT), (re_indent, TOK_INDENT), ... (re_string, TOK_STRING), ) # if is actually re.compile(x), then tokens get bundled with # matchers as they are compiled. This strikes me as good. for matcher,tok in match_tok: m = matcher.match(s) if m: process(tok, m.group(1) break else: raise InvalidTokenError(s) Notice how nicely Python's rather unique for-else clause handles the default case. Terry Jan Reedy From andrew at atoulou.se Wed Jul 9 13:42:19 2008 From: andrew at atoulou.se (Andrew Toulouse) Date: Wed, 9 Jul 2008 04:42:19 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> Message-ID: If I'm understanding you correctly, this would address something I've wanted list comprehensions to do for a little while: [x for x in range(0,10) until greaterthanN(4,x)] or, trying to take from the above example, tokenchecks = [token for regex,token in match_tok until regex.match(s)] # do whatever from this point forward. return tokenchecks[-1] This ignores the case where you might want to bind a name to the expression in an if and until to prevent redundancy, like so: tokenchecks = [token for regex,token in match_tok until regex.match(s) != None if regex.match(s)] #"!= None" included to make the point that you can evaluate more than simple presence of a value if len(tokenchecks) == 0: #do stuff else: process(tokenchecks[-1]) Perhaps you could add some variable binding in there (...maaaaybe.): #Bad example? tokenchecks = [token for regex,token in match_tok until MatchP != None if MatchP with MatchP as regex.match(s)] #Better example? tokenchecks = [token for regex,token in match_tok until MatchP.group(0) == 'somethingspecific' if MatchP with MatchP as regex.match(s)] There are arguments for or against making list comprehensions more complex to accommodate what I hope I understand this thread is getting at, but this is my two cents on a possible syntax. It seems the pattern (or idiom, or whatever the proper term is) of stopping a loop that operates on data before you're done is common enough to justify it. One could argue that this complicates list comprehensions needlessly, or one could argue that list comprehensions already do what for loops can, but serve as shortcuts for common patterns. It also occurs to me that this may not net as much benefits in parallel (or OTOH it could make it easier), but as I do not have significant experience in parallel programming I'll shy away from further commenting. I'm tired and this email has undergone several revisions late at night on an empty stomach. I apologize for the resulting strangeness or disjointedness, if any. Come to think of it, my example might be worse than my fatigued brain is allowing me to believe. --Andy Afterthought: what would happen if the 'until' and 'if' conditions were opposite? Presumably, if the until were never fulfilled, all elements would be present, but if the reverse were true, would it filter out the result, then, and stop? On Tue, Jul 8, 2008 at 11:16 AM, Terry Reedy wrote: > > > Talin wrote: > > I'm actually more interested in the "as" clause being added to "if" rather >> than "while". The specific use case I am thinking is matching regular >> expressions, like so: >> >> def match_token(s): >> # Assume we have regex's precompiled for the various tokens: >> if re_comment.match(s) as m: >> # Do something with m >> process(TOK_COMMENT, m.group(1)) >> elif re_ident.match(s) as m: >> # Do something with m >> process(TOK_IDENT, m.group(1)) >> elif re_integer.match(s) as m: >> # Do something with m >> process(TOK_INT, m.group(1)) >> elif re_float.match(s) as m: >> # Do something with m >> process(TOK_COMMENT, m.group(1)) >> elif re_string.match(s) as m: >> # Do something with m >> process(TOK_STRING, m.group(1)) >> else: >> raise InvalidTokenError(s) >> >> In other words, the general design pattern is one where you have a series >> of tests, where each test can return either None, or an object that you want >> to examine further. >> > > One of the things I do not like above is the repetition of the assignment > target, and statement ends, where it is a little hard to see if it is > spelled the same each time. I think it would be more productive to work on > adding to the stdlib a standardized store-and-test class -- something like > what others have posted on c.l.p. In the below, I factored out the null > test value(s) from the repeated if tests and added it to the pocket instance > as a nulls test attribute. > > def pocket(): > def __init__(self, nulls): > if type(nul;s) != tuple or nulls == (): > nulls = (nulls,) > self.nulls = nulls > def __call__(self, value): > self.value = value > return self > def __bool__(self) > return not (self.value in self.nulls) > > then > > def match_token(s): > # Assume we have regex's precompiled for the various tokens: > p = pocket(None) # None from above, I don't know match return > if p(re_comment.match(s)): > # Do something with p.value > process(TOK_COMMENT, p.value.group(1)) > elif p(re_ident.match(s)): > # Do something with p.value > process(TOK_IDENT, p.value.group(1)) > elif p(re_integer.match(s)): > # etc > > Pocket could be used for the while case, but I will not show that because I > strongly feel 'for item in iteratot' is the proper idiom. > > Your specific example is so regular that it also could be written (better > in my opinion) as a for loop by separating what varies from what does not: > > match_tok = ( > (re_comment, TOK_COMMENT), > (re_indent, TOK_INDENT), > ... > (re_string, TOK_STRING), > ) > # if is actually re.compile(x), then tokens get bundled with > # matchers as they are compiled. This strikes me as good. > > for matcher,tok in match_tok: > m = matcher.match(s) > if m: > process(tok, m.group(1) > break > else: > raise InvalidTokenError(s) > > Notice how nicely Python's rather unique for-else clause handles the > default case. > > Terry Jan Reedy > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrr at ronadam.com Wed Jul 9 16:49:36 2008 From: rrr at ronadam.com (Ron Adam) Date: Wed, 09 Jul 2008 09:49:36 -0500 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> Message-ID: <4874D000.5060902@ronadam.com> Terry Reedy wrote: > Your specific example is so regular that it also could be written > (better in my opinion) as a for loop by separating what varies from what > does not: > > match_tok = ( > (re_comment, TOK_COMMENT), > (re_indent, TOK_INDENT), > ... > (re_string, TOK_STRING), > ) > # if is actually re.compile(x), then tokens get bundled with > # matchers as they are compiled. This strikes me as good. > > for matcher,tok in match_tok: > m = matcher.match(s) > if m: > process(tok, m.group(1) > break > else: > raise InvalidTokenError(s) > > Notice how nicely Python's rather unique for-else clause handles the > default case. > > Terry Jan Reedy This is the same solution I came up with. It separates the data from the code in a way that is much easier to read and maintain. Any time I see more than 3 elif's or else's, It's a hint for me to look for a more generalized solution like this. Ron From tjreedy at udel.edu Wed Jul 9 19:44:31 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 09 Jul 2008 13:44:31 -0400 Subject: [Python-ideas] Openine unicode files In-Reply-To: <92793.41064.qm@web27403.mail.ukl.yahoo.com> References: <92793.41064.qm@web27403.mail.ukl.yahoo.com> Message-ID: Noorhan Abbas wrote: > Hello, > I wonder if someone can advise me on how to open unicode utf-8 files > without using the codecs library . I am trying to use the codecs.open() > from within Google Appengine but it is not working. When posting about something 'not working', post at least a line of code and the resulting exception traceback, if there is one, or a printing of the erroneous value, if that instead is the problem. From greg.ewing at canterbury.ac.nz Thu Jul 10 01:59:26 2008 From: greg.ewing at canterbury.ac.nz (Greg Ewing) Date: Thu, 10 Jul 2008 11:59:26 +1200 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> Message-ID: <487550DE.50309@canterbury.ac.nz> Andrew Toulouse wrote: > tokenchecks = [token for regex,token in match_tok until regex.match(s)] > # do whatever from this point forward. > return tokenchecks[-1] This is an abuse of list comprehensions, since you're throwing away the produced list and only keeping the last element. -- Greg From andrew at atoulou.se Fri Jul 11 11:10:48 2008 From: andrew at atoulou.se (Andrew Akira Toulouse) Date: Fri, 11 Jul 2008 02:10:48 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <487550DE.50309@canterbury.ac.nz> References: <486CDCF5.6080805@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> <487550DE.50309@canterbury.ac.nz> Message-ID: Clearly, the list comprehension is intended to map and filter in a functional matter. My [-1] operation was a trivial reduce operation. Certainly another example could be concocted to demonstrate it used in such a matter that would not offend your sensibilities, but as far as I'm concerned it is simple, beautiful, readable, unambiguous, etc. Your counterpoint takes exception to the example rather than the suggestion. Say someone is going through a flat file with a large list of numbers, and they want to filter out all odd numbers, and stop once they encounter a 0 value. [int(line) for line in file if evenP(int(line)) until int(line)==0] or [int(line) for line in file if evenP(int(line)) until int(line)==0 with open(filename) as file] Bam, one line to open the file, iterate through them, filter out unneeded entries, define the base case, and return value. Do you believe that this also abuses list comprehensions? If so, please explain your reasoning. There's nothing keeping a programmer from writing anything this syntax could do as a normal for loop, but neither is there anything stopping said programmer from using a for loop with ifs and breaks in place of a list comprehension. One can also make the reasoning that for infinitely iterable sequences, in order for the shorter syntax to remain useful it should be able to define a stopping point at which it ceases to map over said sequence. This is my justification for suggesting 'until'; say someone created a function that yielded the fibonacci numbers: it would be easy to iterate over this with a full for statement and forget or misplace the base case which in turn would lead to an infinite loop. 'until' offers a relatively simple solution that at worst adds a few words to a program; on average, could reduce a little bit of processing time; and at best, prevents an infinite for loop -- all in a simple, readable, and compact syntax that, as far as I know (I admit I am very new to python-ideas), would add little complexity to the interpreter. --Andy On Wed, Jul 9, 2008 at 4:59 PM, Greg Ewing wrote: > Andrew Toulouse wrote: > > tokenchecks = [token for regex,token in match_tok until regex.match(s)] >> # do whatever from this point forward. >> return tokenchecks[-1] >> > > This is an abuse of list comprehensions, since > you're throwing away the produced list and only > keeping the last element. > > -- > Greg > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From josiah.carlson at gmail.com Fri Jul 11 18:59:45 2008 From: josiah.carlson at gmail.com (Josiah Carlson) Date: Fri, 11 Jul 2008 09:59:45 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> <487550DE.50309@canterbury.ac.nz> Message-ID: Not everything should be a 1-line function or operation. And, in fact, your examples show that you really don't understand *current* Python semantics, so trying to introduce new syntax is a non-starter (never mind that it was killed earlier). [int(line) for line in file if evenP(int(line)) until int(line)==0 with open(filename) as file] Could be replaced by... [int(line) for line in open(filename) if evenP(int(line)) until int(line)==0] If you kept the until syntax. But even then, since Python files iterate lines with trailing newlines, it would raise an exception in the first pass. [int(line.rstrip('\r\n')) for line in open(filename) if evenP(int(line.rstrip('\r\n')) until ...] But now there's all this .rstrip() crap in there, an explicit evenP call, etc. At this point, it's probably *clearer* (and faster) to pull everything out and be explicit about your cases. out = [] for line in open(filename): val = int(line.rstrip('\r\n')) if val == 0: break if not val & 1: out.append(val) - Josiah On Fri, Jul 11, 2008 at 2:10 AM, Andrew Akira Toulouse wrote: > Clearly, the list comprehension is intended to map and filter in a > functional matter. My [-1] operation was a trivial reduce operation. > Certainly another example could be concocted to demonstrate it used in such > a matter that would not offend your sensibilities, but as far as I'm > concerned it is simple, beautiful, readable, unambiguous, etc. > > Your counterpoint takes exception to the example rather than the suggestion. > Say someone is going through a flat file with a large list of numbers, and > they want to filter out all odd numbers, and stop once they encounter a 0 > value. > > [int(line) for line in file if evenP(int(line)) until int(line)==0] > > or > > [int(line) for line in file if evenP(int(line)) until int(line)==0 with > open(filename) as file] > > Bam, one line to open the file, iterate through them, filter out unneeded > entries, define the base case, and return value. > > Do you believe that this also abuses list comprehensions? If so, please > explain your reasoning. > > There's nothing keeping a programmer from writing anything this syntax could > do as a normal for loop, but neither is there anything stopping said > programmer from using a for loop with ifs and breaks in place of a list > comprehension. > > One can also make the reasoning that for infinitely iterable sequences, in > order for the shorter syntax to remain useful it should be able to define a > stopping point at which it ceases to map over said sequence. This is my > justification for suggesting 'until'; say someone created a function that > yielded the fibonacci numbers: it would be easy to iterate over this with a > full for statement and forget or misplace the base case which in turn would > lead to an infinite loop. 'until' offers a relatively simple solution that > at worst adds a few words to a program; on average, could reduce a little > bit of processing time; and at best, prevents an infinite for loop -- all in > a simple, readable, and compact syntax that, as far as I know (I admit I am > very new to python-ideas), would add little complexity to the interpreter. > > --Andy > > On Wed, Jul 9, 2008 at 4:59 PM, Greg Ewing > wrote: >> >> Andrew Toulouse wrote: >> >>> tokenchecks = [token for regex,token in match_tok until regex.match(s)] >>> # do whatever from this point forward. >>> return tokenchecks[-1] >> >> This is an abuse of list comprehensions, since >> you're throwing away the produced list and only >> keeping the last element. >> >> -- >> Greg >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas at python.org >> http://mail.python.org/mailman/listinfo/python-ideas > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > > From guido at python.org Thu Jul 17 19:22:27 2008 From: guido at python.org (Guido van Rossum) Date: Thu, 17 Jul 2008 10:22:27 -0700 Subject: [Python-ideas] Unittest PEP do's and don'ts (BDFL pronouncement) In-Reply-To: References: Message-ID: Please move all discussions of unittest frameworks to python-ideas at python.org. It is an interesting topic -- so interesting, in fact, that exploring all the different ideas under discussion is overwhelming the primary purpose of python-dev, which at this point is to get the 2.6 and 3.0 releases into shape. -- --Guido van Rossum (home page: http://www.python.org/~guido/) From fdrake at acm.org Thu Jul 17 19:38:13 2008 From: fdrake at acm.org (Fred Drake) Date: Thu, 17 Jul 2008 13:38:13 -0400 Subject: [Python-ideas] Unittest PEP do's and don'ts (BDFL pronouncement) In-Reply-To: References: Message-ID: On Jul 17, 2008, at 1:22 PM, Guido van Rossum wrote: > Please move all discussions of unittest frameworks to > python-ideas at python.org. It is an interesting topic -- so interesting, There's also the testing-in-python list: http://lists.idyll.org/listinfo/testing-in-python -Fred -- Fred Drake From stefan_ml at behnel.de Fri Jul 18 10:51:25 2008 From: stefan_ml at behnel.de (Stefan Behnel) Date: Fri, 18 Jul 2008 10:51:25 +0200 Subject: [Python-ideas] Ideas towards GIL removal In-Reply-To: <461F285F.4060003@acm.org> References: <461ED2F9.9020407@canterbury.ac.nz> <461F285F.4060003@acm.org> Message-ID: Talin wrote: > I'm thinking along similar lines, but my approach is to eliminate > refcounting entirely. (Note that the incref and decref macros could > still exist for backwards compatibility, but would do nothing.) There was a PyPy talk at this year's EuroPython about "writing code for different GCs". Certainly worth reading in this context. Bottom-line being that it's always worth thinking about the effect of ref-counting on code and if the code would still work if there was no ref-counting (as in Jython, PyPy and IronPython). Sometimes not as obvious as it might seem... Stefan From idadesub at users.sourceforge.net Mon Jul 21 00:52:18 2008 From: idadesub at users.sourceforge.net (Erick Tryzelaar) Date: Sun, 20 Jul 2008 15:52:18 -0700 Subject: [Python-ideas] fnmatch/glob with sub-expressions Message-ID: <1ef034530807201552y7ece81b3p6e88f94a2f867a2b@mail.gmail.com> I need to handle more advanced glob pattern matching than what glob/fnmatch provides. I need to support patterns like this: "a{b*c,d[ef]}" -> "a(b.*c|d[ef])$" "a{b{c,d},e}" -> "a(b(c|d)|e)$" This syntax is used in many shells, like bash and zsh, and other languages, like ruby. Does anyone else think this might be worthwhile in the standard library? It's a pretty simple change, but it could break code though, so we'd probably have to disable it by default. From aahz at pythoncraft.com Mon Jul 21 00:55:41 2008 From: aahz at pythoncraft.com (Aahz) Date: Sun, 20 Jul 2008 15:55:41 -0700 Subject: [Python-ideas] fnmatch/glob with sub-expressions In-Reply-To: <1ef034530807201552y7ece81b3p6e88f94a2f867a2b@mail.gmail.com> References: <1ef034530807201552y7ece81b3p6e88f94a2f867a2b@mail.gmail.com> Message-ID: <20080720225541.GA5185@panix.com> On Sun, Jul 20, 2008, Erick Tryzelaar wrote: > > I need to handle more advanced glob pattern matching than what > glob/fnmatch provides. I need to support patterns like this: > > "a{b*c,d[ef]}" -> "a(b.*c|d[ef])$" > "a{b{c,d},e}" -> "a(b(c|d)|e)$" > > This syntax is used in many shells, like bash and zsh, and other > languages, like ruby. Does anyone else think this might be worthwhile > in the standard library? It's a pretty simple change, but it could > break code though, so we'd probably have to disable it by default. Patches are probably welcome, but I think most people use os.listdir() combined with re to handle such matching. (That's certainly what I do.) -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ Adopt A Process -- stop killing all your children! From jacobolus at gmail.com Tue Jul 29 03:53:32 2008 From: jacobolus at gmail.com (Jacob Rus) Date: Mon, 28 Jul 2008 18:53:32 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> <487550DE.50309@canterbury.ac.nz> Message-ID: Andrew Akira Toulouse wrote: > Your counterpoint takes exception to the example rather than the suggestion. > Say someone is going through a flat file with a large list of numbers, and > they want to filter out all odd numbers, and stop once they encounter a 0 > value. [...] > > [int(line) for line in file if evenP(int(line)) until int(line)==0 with > open(filename) as file] > > Bam, one line to open the file, iterate through them, filter out unneeded > entries, define the base case, and return value. > > Do you believe that this also abuses list comprehensions? If so, please > explain your reasoning. > > There's nothing keeping a programmer from writing anything this syntax could > do as a normal for loop, but neither is there anything stopping said > programmer from using a for loop with ifs and breaks in place of a list > comprehension. Since you don't like for loops, what's wrong with: from itertools import takewhile with open(filename) as f: intlines = (int(line) for line in f if evenP(int(line))) result = list(takewhile(lambda x: x, intlines)) This is perfectly clear, not too much longer than your suggestion, and doesn't require adding large amounts of extra syntax to the language (though using a lambda for the identity function is a bit more verbose than I'd prefer). Personally, I?d rather have this broken up than in one gigantic line that looks like: result = [int(line) for line in f if evenP(int(line)) until int(line) == 0 with open(filename) as f] As for: > tokenchecks = [token for regex,token in match_tok until regex.match(s)] > return tokenchecks[-1] This is much more readably expressed as: for regexp, token in match_tok: if regexp.match(s): return token Cheers, Jacob Rus From tjreedy at udel.edu Tue Jul 29 11:27:20 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 29 Jul 2008 05:27:20 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> <487550DE.50309@canterbury.ac.nz> Message-ID: Jacob Rus wrote: > Andrew Akira Toulouse wrote: >> tokenchecks = [token for regex,token in match_tok until >> regex.match(s)] return tokenchecks[-1] This is missing either ';' or '\n' between the statements. > > This is much more readably expressed as: > > for regexp, token in match_tok: > if regexp.match(s): > return token Besides which, creating an unbounded list one does not actually want strikes me as conceptually ugly ;-). From rnd at onego.ru Tue Jul 29 12:15:40 2008 From: rnd at onego.ru (Roman Susi) Date: Tue, 29 Jul 2008 13:15:40 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <486CE904.2040403@vector-seven.com> <740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> <487550DE.50309@canterbury.ac.nz> Message-ID: <488EEDCC.7050303@onego.ru> hi! Jacob Rus wrote: > Andrew Akira Toulouse wrote: ... > Personally, I?d rather have this broken up than in one gigantic line > that looks like: > > result = [int(line) for line in f if evenP(int(line)) > until int(line) == 0 with open(filename) as f] I have not followed the thread, but the line above looks cool and terrible at the same time. I can't think what other operator can be squeezed into expression, maybe try-except, eh? result = [int(line) for line in f try if evenP(int(line)) until int(line) == 0 except ValueError("blabla") with open(filename) as f] I am not sure if this kind of SQLness should enter Python syntax at all... Regards, Roman > > As for: > >> tokenchecks = [token for regex,token in match_tok until >> regex.match(s)] return tokenchecks[-1] > > This is much more readably expressed as: > > for regexp, token in match_tok: > if regexp.match(s): > return token > > > Cheers, > Jacob Rus > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > > !DSPAM:488e7c4d23202007710671! > From andrew at atoulou.se Tue Jul 29 18:55:05 2008 From: andrew at atoulou.se (Andrew Akira Toulouse) Date: Tue, 29 Jul 2008 09:55:05 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: <488EEDCC.7050303@onego.ru> References: <486CDCF5.6080805@korokithakis.net> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> <487550DE.50309@canterbury.ac.nz> <488EEDCC.7050303@onego.ru> Message-ID: Point taken -- it's a very valid point, but at the same time building an unnecessary list isn't really all that good-looking. Being able to do query-like things is very useful, and I'd prefer to do it as close to the Python core as possible, rather than (for example) creating a in-memory sqlite database or something. LINQ, I think, somewhat validates this point of view. I feel that an integrated way to query data would be a useful addition. List comprehensions seem to be the natural Pythonic way to do this, but if you can think of something better... On Tue, Jul 29, 2008 at 3:15 AM, Roman Susi wrote: > hi! > > Jacob Rus wrote: > > Andrew Akira Toulouse wrote: > > ... > > > Personally, I'd rather have this broken up than in one gigantic line > > that looks like: > > > > result = [int(line) for line in f if evenP(int(line)) > > until int(line) == 0 with open(filename) as f] > > > I have not followed the thread, but the line above looks cool and > terrible at the same time. > > I can't think what other operator can be squeezed into expression, maybe > try-except, eh? > > result = [int(line) for line in f try if evenP(int(line)) > until int(line) == 0 except ValueError("blabla") > with open(filename) as f] > > > I am not sure if this kind of SQLness should enter Python syntax at all... > > Regards, > Roman > > > > > As for: > > > >> tokenchecks = [token for regex,token in match_tok until > >> regex.match(s)] return tokenchecks[-1] > > > > This is much more readably expressed as: > > > > for regexp, token in match_tok: > > if regexp.match(s): > > return token > > > > > > Cheers, > > Jacob Rus > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas at python.org > > http://mail.python.org/mailman/listinfo/python-ideas > > > > !DSPAM:488e7c4d23202007710671! > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rrr at ronadam.com Tue Jul 29 19:49:52 2008 From: rrr at ronadam.com (Ron Adam) Date: Tue, 29 Jul 2008 12:49:52 -0500 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> <487550DE.50309@canterbury.ac.nz> <488EEDCC.7050303@onego.ru> Message-ID: <488F5840.6000206@ronadam.com> Andrew Akira Toulouse wrote: > Point taken -- it's a very valid point, but at the same time building an > unnecessary list isn't really all that good-looking. Being able to do > query-like things is very useful, and I'd prefer to do it as close to > the Python core as possible, rather than (for example) creating a > in-memory sqlite database or something. LINQ, I think, somewhat > validates this point of view. I feel that an integrated way to query > data would be a useful addition. List comprehensions seem to be the > natural Pythonic way to do this, but if you can think of something better... How about something liter, like a function that searches containers in a way similar to how Yahoo searches are expressed. While this can be done with regex expressions, they aren't something you want to expose to a typical user. It would be a good candidate for a separately developed module that may could be included in the library at some point in the future. Ron > On Tue, Jul 29, 2008 at 3:15 AM, Roman Susi > wrote: > > hi! > > Jacob Rus wrote: > > Andrew Akira Toulouse wrote: > > ... > > > Personally, I'd rather have this broken up than in one gigantic line > > that looks like: > > > > result = [int(line) for line in f if evenP(int(line)) > > until int(line) == 0 with open(filename) as f] > > > I have not followed the thread, but the line above looks cool and > terrible at the same time. > > I can't think what other operator can be squeezed into expression, maybe > try-except, eh? > > result = [int(line) for line in f try if evenP(int(line)) > until int(line) == 0 except ValueError("blabla") > with open(filename) as f] > > > I am not sure if this kind of SQLness should enter Python syntax at > all... > > Regards, > Roman > > > > > As for: > > > >> tokenchecks = [token for regex,token in match_tok until > >> regex.match(s)] return tokenchecks[-1] > > > > This is much more readably expressed as: > > > > for regexp, token in match_tok: > > if regexp.match(s): > > return token > > > > > > Cheers, > > Jacob Rus > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas at python.org > > http://mail.python.org/mailman/listinfo/python-ideas > > > > !DSPAM:488e7c4d23202007710671! > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas From rnd at onego.ru Tue Jul 29 20:42:47 2008 From: rnd at onego.ru (Roman Susi) Date: Tue, 29 Jul 2008 21:42:47 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> <487550DE.50309@canterbury.ac.nz> <488EEDCC.7050303@onego.ru> Message-ID: <488F64A7.9010902@onego.ru> Andrew Akira Toulouse wrote: > Point taken -- it's a very valid point, but at the same time building an > unnecessary list isn't really all that good-looking. Being able to do > query-like things is very useful, and I'd prefer to do it as close to > the Python core as possible, rather than (for example) creating a > in-memory sqlite database or something. LINQ, I think, somewhat > validates this point of view. I feel that an integrated way to query > data would be a useful addition. List comprehensions seem to be the > natural Pythonic way to do this, but if you can think of something better... What I am not sure about is that Python needs special syntactic provisions for "query-like" things even though its temptative and I am sure a lot of use cases can be facilitated (not only SQL queries but Prolog-like, SPARQL-like, etc, etc). Because it makes the language unnecessarily complex. Python already has dict/list literals + list comprehensions. And universal functional syntax could be used for the same things if only Python easier "laziness", because all those proposed untils and while could be then simply realized as functions. The below is not syntax proposition, but illustrates what I mean: my_qry = select(` from(t1=`table1), ` where(`t1.somefield < 5), ...) Those things after backticks function select can eval if needed. Similarly, there could be triple backtick for lazy expressions as a whole: qry = ```select(from(t2=table), where(...), ... ``` which could be then evaluated accordind to some domain-specific language (Python syntax for domain specific language): res = sqlish(qry) One obvious usage is regular expressions. Right now ``` is just r""" for them. And sqlish() above is re.compile(). In short, I do not like ad hoc additions to the language (even inline if was imho a compromise), but more generic features (syntactic support for embedded declarative/query languages) like simple lazy evaluation. (PEP 312 "Simple implicit lambda" co-authored by me is just one example toward same goal of simpler laziness.) Please, do not understand me wrong. I am not against adding features you want/need and many people who design ORMs and the likes will be glad to see in Python. I am against making particular syntactic changes to Python to enable those features instead of thinking on more generic feature which would cover many cases. And I think that feature boils down to something spiritually like Lisp's quote. The syntax above reuses backtick dropped by Py3k to mean not just a string to evaluate but a closure. Its possible to do those things with lambdas even now but the readability will suffer to the degree of unpythonic code. Also, its possible to do the same (and there are a lot of examples like PyParsing) with specially crafted classes which overload all operations to perform their logic in a lazy evaluation fashion (that is, function calls are not really function calls any more but data structure specifiers/builders). Sorry for going too far from the original topic. I just wanted to point out that IMHO the while/until feature is not quite good for Python as very specific syntactic addition. I do not believe GvR will ever make list comprehensions complete sql with wheres, groupings, orderbys, havings, limits, even though for (SQL's from) and if (SQL's where) are there. Regards, Roman > On Tue, Jul 29, 2008 at 3:15 AM, Roman Susi > wrote: > > hi! > > Jacob Rus wrote: > > Andrew Akira Toulouse wrote: > > ... > > > Personally, I'd rather have this broken up than in one gigantic line > > that looks like: > > > > result = [int(line) for line in f if evenP(int(line)) > > until int(line) == 0 with open(filename) as f] > > > I have not followed the thread, but the line above looks cool and > terrible at the same time. > > I can't think what other operator can be squeezed into expression, maybe > try-except, eh? > > result = [int(line) for line in f try if evenP(int(line)) > until int(line) == 0 except ValueError("blabla") > with open(filename) as f] > > > I am not sure if this kind of SQLness should enter Python syntax at > all... > > Regards, > Roman > > > > > As for: > > > >> tokenchecks = [token for regex,token in match_tok until > >> regex.match(s)] return tokenchecks[-1] > > > > This is much more readably expressed as: > > > > for regexp, token in match_tok: > > if regexp.match(s): > > return token > > > > > > Cheers, > > Jacob Rus > > > > _______________________________________________ > > Python-ideas mailing list > > Python-ideas at python.org > > http://mail.python.org/mailman/listinfo/python-ideas > > > > > > > > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > > > !DSPAM:488f4b7828356531321995! From tjreedy at udel.edu Tue Jul 29 23:19:00 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 29 Jul 2008 17:19:00 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: <488F64A7.9010902@onego.ru> References: <486CDCF5.6080805@korokithakis.net> <088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org> <4872CCA9.1040908@acm.org> <487550DE.50309@canterbury.ac.nz> <488EEDCC.7050303@onego.ru> <488F64A7.9010902@onego.ru> Message-ID: Roman Susi wrote: > Python already has dict/list literals + list comprehensions. Better to think that Python has generator expressions which can be used in list, set, and dict comprehensions (the latter two in 3.0 and maybe 2.6). > universal functional syntax could be used for the same things if only > Python easier "laziness", because all those proposed untils and while > could be then simply realized as functions. Generator functions using loops and alternation are easy laziness for cases not easily abbreviated by generator expressions. I see no reason to complicate the language with new keywords. tjr From steven.bethard at gmail.com Wed Jul 30 00:04:47 2008 From: steven.bethard at gmail.com (Steven Bethard) Date: Tue, 29 Jul 2008 16:04:47 -0600 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <487550DE.50309@canterbury.ac.nz> <488EEDCC.7050303@onego.ru> <488F64A7.9010902@onego.ru> Message-ID: On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy wrote: > Roman Susi wrote: >> Python already has dict/list literals + list comprehensions. > > Better to think that Python has generator expressions which can be used in > list, set, and dict comprehensions (the latter two in 3.0 and maybe 2.6). You probably don't want to think about it that way - a list/set/dict comprehension does not actually create a generator. Instead, it basically just inlines the equivalent for loop. Note that there's no YIELD_VALUE opcode for the comprehensions: >>> def dict_comp(x, y): ... return {z:x for z in y} ... >>> def dict_gen(x, y): ... return dict((z, x) for z in y) ... >>> dis.dis(dict_comp.__code__.co_consts[1]) 2 0 BUILD_MAP 0 3 DUP_TOP 4 STORE_FAST 1 (_[1]) 7 LOAD_FAST 0 (.0) >> 10 FOR_ITER 17 (to 30) 13 STORE_FAST 2 (z) 16 LOAD_FAST 1 (_[1]) 19 LOAD_DEREF 0 (x) 22 ROT_TWO 23 LOAD_FAST 2 (z) 26 STORE_SUBSCR 27 JUMP_ABSOLUTE 10 >> 30 RETURN_VALUE >>> dis.dis(dict_gen.__code__.co_consts[1]) 2 0 LOAD_FAST 0 (.0) >> 3 FOR_ITER 17 (to 23) 6 STORE_FAST 1 (z) 9 LOAD_FAST 1 (z) 12 LOAD_DEREF 0 (x) 15 BUILD_TUPLE 2 18 YIELD_VALUE 19 POP_TOP 20 JUMP_ABSOLUTE 3 >> 23 LOAD_CONST 0 (None) 26 RETURN_VALUE Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From tjreedy at udel.edu Wed Jul 30 04:55:51 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Tue, 29 Jul 2008 22:55:51 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <487550DE.50309@canterbury.ac.nz> <488EEDCC.7050303@onego.ru> <488F64A7.9010902@onego.ru> Message-ID: Steven Bethard wrote: > On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy wrote: >> Roman Susi wrote: >>> Python already has dict/list literals + list comprehensions. >> Better to think that Python has generator expressions which can be used in >> list, set, and dict comprehensions (the latter two in 3.0 and maybe 2.6). > > You probably don't want to think about it that way - a list/set/dict > comprehension does not actually create a generator. Yes I do. For normal purposes, in 3.0, [genexp] == list(genexp), and so on. That it do something else internally for efficiency is implementation detail, not semantics. > Instead, it basically just inlines the equivalent for loop. In 3.0, not quite. The manual says "Note that the comprehension is executed in a separate scope, so names assigned to in the target list don?t ?leak? in the enclosing scope." The difference between this and the conceptual equivalence above is one function call versus many. Were you using 2.6? tjr From steven.bethard at gmail.com Wed Jul 30 07:29:23 2008 From: steven.bethard at gmail.com (Steven Bethard) Date: Tue, 29 Jul 2008 23:29:23 -0600 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <487550DE.50309@canterbury.ac.nz> <488EEDCC.7050303@onego.ru> <488F64A7.9010902@onego.ru> Message-ID: On Tue, Jul 29, 2008 at 8:55 PM, Terry Reedy wrote: > Steven Bethard wrote: >> On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy wrote: >>> Roman Susi wrote: >>>> Python already has dict/list literals + list comprehensions. >>> >>> Better to think that Python has generator expressions which can be used >>> in list, set, and dict comprehensions (the latter two in 3.0 and maybe 2.6). >> >> You probably don't want to think about it that way - a list/set/dict >> comprehension does not actually create a generator. > > Yes I do. For normal purposes, in 3.0, [genexp] == list(genexp), and so on. > That it do something else internally for efficiency is implementation > detail, not semantics. But the semantics are pretty different. The semantics are basically: def _(seq): _1 = [] for x in seq: _1.append() return _1 return _(seq) def _(seq): for x in seq: yield return list(_(seq)) Yes, they produce the same results, but semantically they're different. In one case, a list is created and items are appended to it and then that list is returned. In the other case, a generator object is created, and then that generator is repeatedly resumed to yield items by the list() constructor. I think it's fine to say they achieve the same result, but I think saying they're really the same thing is a mistake. Steve P.S. Yes, it's executed in a different scope - that's why the code I showed you before had to do ``dict_comp.__code__.co_consts[1]`` instead of just ``dict_comp.__code__``. -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From rnd at onego.ru Wed Jul 30 08:25:59 2008 From: rnd at onego.ru (Roman Susi) Date: Wed, 30 Jul 2008 09:25:59 +0300 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <487550DE.50309@canterbury.ac.nz> <488EEDCC.7050303@onego.ru> <488F64A7.9010902@onego.ru> Message-ID: <48900977.6050703@onego.ru> Steven Bethard wrote: > On Tue, Jul 29, 2008 at 8:55 PM, Terry Reedy wrote: >> Steven Bethard wrote: >>> On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy wrote: >>>> Roman Susi wrote: >>>>> Python already has dict/list literals + list comprehensions. >>>> Better to think that Python has generator expressions which can be used >>>> in list, set, and dict comprehensions (the latter two in 3.0 and maybe 2.6). >>> You probably don't want to think about it that way - a list/set/dict >>> comprehension does not actually create a generator. >> Yes I do. For normal purposes, in 3.0, [genexp] == list(genexp), and so on. >> That it do something else internally for efficiency is implementation >> detail, not semantics. First of all, the difference in semantics is not that crucial for the point I made (no extra syntax for Python built-in "query language"). Both ways (list comprehensions and generators) are ways to abstract iterative processing of items of some data structures (they are iterative) where generators are much more generic. The problem is not on the result side. Syntax proposed for while/until and other possible additions (try-except, with) are basically the filters in the pipeline which are possible to do with functional approach (using generator protocol or not and whether or not it is good "laziness" - is a matter of implementation) without introducing obscure syntactic additions and new or reused keywords. As someone pointed out, maybe more advanced itertools / "gentools" can achieve desired results without loosing efficiency but helping readable iterators/generators pipeline construction for modeling query languages. -Roman > But the semantics are pretty different. The semantics are basically: > > def _(seq): > _1 = [] > for x in seq: > _1.append() > return _1 > return _(seq) > > def _(seq): > for x in seq: > yield > return list(_(seq)) > > Yes, they produce the same results, but semantically they're > different. In one case, a list is created and items are appended to it > and then that list is returned. In the other case, a generator object > is created, and then that generator is repeatedly resumed to yield > items by the list() constructor. > > I think it's fine to say they achieve the same result, but I think > saying they're really the same thing is a mistake. > > Steve > > P.S. Yes, it's executed in a different scope - that's why the code I > showed you before had to do ``dict_comp.__code__.co_consts[1]`` > instead of just ``dict_comp.__code__``. > > From tjreedy at udel.edu Wed Jul 30 17:00:46 2008 From: tjreedy at udel.edu (Terry Reedy) Date: Wed, 30 Jul 2008 11:00:46 -0400 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <487550DE.50309@canterbury.ac.nz> <488EEDCC.7050303@onego.ru> <488F64A7.9010902@onego.ru> Message-ID: Steven Bethard wrote: > On Tue, Jul 29, 2008 at 8:55 PM, Terry Reedy wrote: >> Steven Bethard wrote: >>> On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy wrote: >>>> Roman Susi wrote: >>>>> Python already has dict/list literals + list comprehensions. I could have mentioned here that Python does not have dict or list *literals*. It only have number and string/bytes literals. It has set, dict, and list *displays*. One form of display content is a sequence of expressions, a tuple list (with a special form for dicts). Another form of display content is a genexp (with a special form for dict comprehensions). >>>> Better to think that Python has generator expressions which can be used >>>> in list, set, and dict comprehensions (the latter two in 3.0 and maybe 2.6). The above is a slightly better way to say this. >>> You probably don't want to think about it that way - a list/set/dict >>> comprehension does not actually create a generator. I never said it necessarily did. The fact that [tuple_list] == list((tuple_list)) does not mean that [tuple_list] actually creates a tuple object. An interpreter could, but CPython does not. Similarly, f(1,2,3) could create a tuple object, but CPython does not. >> Yes I do. For normal purposes, in 3.0, [genexp] == list(genexp), and so on. >> That it do something else internally for efficiency is implementation >> detail, not semantics. > > But the semantics are pretty different. I never said that listcomp == genexp, I said that listcomp (setcomp,dictcomp) == bracketed genexp == list/set/dict(genexp) The semantics are basically: > > def _(seq): > _1 = [] > for x in seq: > _1.append() > return _1 > return _(seq) > > def _(seq): > for x in seq: > yield > return list(_(seq)) > > Yes, they produce the same results, The results of the expressions are their semantics. When you write 547 + 222, the semantics is the result 769, not the internal implementation of how a particular interpreter arrives at that. Anyway, in Python, '==' is value comparison, not algorithm comparison. > but semantically they're > different. In one case, a list is created and items are appended to it > and then that list is returned. In the other case, a generator object > is created, and then that generator is repeatedly resumed to yield > items by the list() constructor. This is a CPython internal implementation choice. In each case, a list object is created and items appended to it. The internal question is how the objects are generated. The list(genexp) implementation was considered until the faster version was created. [genexp] == list(genexp) was the design goal. I said 'for normal purposes' because it turns out that the the faster implementation allows that equality to be broken with somewhat bizarre and abusive code that should never appear in practical code. The developers tried to fix this minor glitch but could not without reverting to the slower list(genexp) version, so they decided to leave things alone. My point is that if one understands genexp, one really understands the comprehensions also. It is a matter of reducing cognitive load. I happen to be in favor of that. Terry Jan Reedy From steven.bethard at gmail.com Wed Jul 30 18:26:49 2008 From: steven.bethard at gmail.com (Steven Bethard) Date: Wed, 30 Jul 2008 10:26:49 -0600 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <488EEDCC.7050303@onego.ru> <488F64A7.9010902@onego.ru> Message-ID: On Wed, Jul 30, 2008 at 9:00 AM, Terry Reedy wrote: > The results of the expressions are their semantics. When you write 547 + > 222, the semantics is the result 769, not the internal implementation of how > a particular interpreter arrives at that. I see we have a very different definition of semantics. For me, the semantics of ``547 + 222`` are different from ``1538 / 2 are different from 769 because the operations the interpreter goes through are different. Given that by "semantics" you mean, "result of the expression", I can happily conceded that the result of the expression of list() is the same as []. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy From borowitz at stanford.edu Wed Jul 30 20:57:13 2008 From: borowitz at stanford.edu (David Borowitz) Date: Wed, 30 Jul 2008 11:57:13 -0700 Subject: [Python-ideas] "While" suggestion In-Reply-To: References: <486CDCF5.6080805@korokithakis.net> <488EEDCC.7050303@onego.ru> <488F64A7.9010902@onego.ru> Message-ID: <70e6cf130807301157v630f8be1pb8dd29e749ae3797@mail.gmail.com> Precisely: you're talking about two different accepted definitions of semantics: http://en.wikipedia.org/wiki/Formal_semantics_of_programming_languages I'm not going to say one type of formal semantics is better than another, but it's nice when everyone is at least on the same page :) On Wed, Jul 30, 2008 at 09:26, Steven Bethard wrote: > On Wed, Jul 30, 2008 at 9:00 AM, Terry Reedy wrote: > > The results of the expressions are their semantics. When you write 547 + > > 222, the semantics is the result 769, not the internal implementation of > how > > a particular interpreter arrives at that. > This is denotational semantics. > I see we have a very different definition of semantics. For me, the > semantics of ``547 + 222`` are different from ``1538 / 2 are different > from 769 because the operations the interpreter goes through are > different. Given that by "semantics" you mean, "result of the > expression", I can happily conceded that the result of the expression > of list() is the same as []. > > Steve This is operational semantics. > > -- > I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a > tiny blip on the distant coast of sanity. > --- Bucky Katt, Get Fuzzy > _______________________________________________ > Python-ideas mailing list > Python-ideas at python.org > http://mail.python.org/mailman/listinfo/python-ideas > -- It is better to be quotable than to be honest. -Tom Stoppard Borowitz -------------- next part -------------- An HTML attachment was scrubbed... URL: