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: <cc7430500806301434s456c4694t4eb0980447461663@mail.gmail.com>
References: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com>
	<cc7430500806301434s456c4694t4eb0980447461663@mail.gmail.com>
Message-ID: <7528bcdd0806301500h5cd94f78w3bbbc92c02e119d9@mail.gmail.com>

On Mon, Jun 30, 2008 at 6:34 PM, Leif Walsh <leif.walsh at gmail.com> wrote:
> On Sun, Jun 29, 2008 at 6:41 PM, Andre Roberge <andre.roberge at gmail.com> 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>
	<cc7430500806301434s456c4694t4eb0980447461663@mail.gmail.com>
	<7528bcdd0806301500h5cd94f78w3bbbc92c02e119d9@mail.gmail.com>
Message-ID: <cc7430500806301504v12aff734gc2b1726726de16a6@mail.gmail.com>

On Mon, Jun 30, 2008 at 3:00 PM, Andre Roberge <andre.roberge at gmail.com> 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: <cc7430500806301504v12aff734gc2b1726726de16a6@mail.gmail.com>
References: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com>
	<cc7430500806301434s456c4694t4eb0980447461663@mail.gmail.com>
	<7528bcdd0806301500h5cd94f78w3bbbc92c02e119d9@mail.gmail.com>
	<cc7430500806301504v12aff734gc2b1726726de16a6@mail.gmail.com>
Message-ID: <c7450fba0806301934m1c7d18bake5a098e948d328d5@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-ideas/attachments/20080630/99de17f6/attachment.html>

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: <c7450fba0806301934m1c7d18bake5a098e948d328d5@mail.gmail.com>
References: <7528bcdd0806291841y7dc202f3y79176461a5d07165@mail.gmail.com>	<cc7430500806301434s456c4694t4eb0980447461663@mail.gmail.com>	<7528bcdd0806301500h5cd94f78w3bbbc92c02e119d9@mail.gmail.com>	<cc7430500806301504v12aff734gc2b1726726de16a6@mail.gmail.com>
	<c7450fba0806301934m1c7d18bake5a098e948d328d5@mail.gmail.com>
Message-ID: <g4dtto$c7g$1@ger.gmane.org>



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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/d098391a/attachment.vcf>

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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/53d9204e/attachment.vcf>

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: <e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>

2008/7/3 Stavros Korokithakis <stavros at korokithakis.net>:

> 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: <e6511dbf0807030750q263faafbsafdd9c20febaee27@mail.gmail.com>

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
<stavros at korokithakis.net> 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: <e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
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 <stavros at korokithakis.net>:
> 
>> 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/6a019dbd/attachment.vcf>

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: <e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
Message-ID: <e6511dbf0807030754td612792ofa16d8522c926e12@mail.gmail.com>

On Thu, Jul 3, 2008 at 7:46 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/7/3 Stavros Korokithakis <stavros at korokithakis.net>:
>
>> 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/0ffdc2b6/attachment.html>

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: <e6511dbf0807030754td612792ofa16d8522c926e12@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>	
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
	<e6511dbf0807030754td612792ofa16d8522c926e12@mail.gmail.com>
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
> <facundobatista at gmail.com> wrote:
>> 2008/7/3 Stavros Korokithakis <stavros at korokithakis.net>:
>>
>>> 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/7e24d614/attachment.vcf>

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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/d2922a98/attachment.vcf>

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 <tom at vector-seven.com> 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 
<expression>" 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 <tom at vector-seven.com> 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/c172fdb9/attachment.vcf>

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: <e04bdf310807030822j1ab94215wbf18943c8372d5bc@mail.gmail.com>

2008/7/3 George Sakkis <george.sakkis at gmail.com>:

> 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
<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)


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: <e04bdf310807030822j1ab94215wbf18943c8372d5bc@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>	<91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com>
	<e04bdf310807030822j1ab94215wbf18943c8372d5bc@mail.gmail.com>
Message-ID: <486CF1F2.9010409@vector-seven.com>

Facundo Batista wrote:
> 2008/7/3 George Sakkis <george.sakkis at gmail.com>:
>
>   
>> 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  
> <expression>" 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 <expr> as  
<var>:" form only handles a specific case (though common).

The "while <expr> as <var>:" 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   <fdrake at acm.org>






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: <e04bdf310807030822j1ab94215wbf18943c8372d5bc@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>
	<91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com>
	<e04bdf310807030822j1ab94215wbf18943c8372d5bc@mail.gmail.com>
Message-ID: <91ad5bf80807030842l1c5607b9kbee186dce88e0796@mail.gmail.com>

On Thu, Jul 3, 2008 at 11:22 AM, Facundo Batista <facundobatista at gmail.com>
wrote:

2008/7/3 George Sakkis <george.sakkis at gmail.com>:
>
> > 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/034abd85/attachment.html>

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: <e04bdf310807030845o1edc9751hd91048851682e740@mail.gmail.com>

2008/7/3 Fred Drake <fdrake at acm.org>:

> The "while <expr> as <var>:" 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>	<e04bdf310807030822j1ab94215wbf18943c8372d5bc@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 <george.sakkis at gmail.com>:
>>
>>  
>>> 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/90dff1c8/attachment.vcf>

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
<stavros at korokithakis.net> 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>	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
	<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" <facundobatista at gmail.com> wrote:
> 
>> 2008/7/3 Stavros Korokithakis <stavros at korokithakis.net>:
>>
>>> 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.
> 
>     <mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stavros.vcf
Type: text/x-vcard
Size: 143 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/ffcb5e31/attachment.vcf>

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: <e04bdf310807030845o1edc9751hd91048851682e740@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>
	<486CEE63.8050800@korokithakis.net>
	<057E8E37-60FE-4B1A-B653-AF953CCDD574@acm.org>
	<e04bdf310807030845o1edc9751hd91048851682e740@mail.gmail.com>
Message-ID: <ca471dc20807030915m53a0bf8et5f4f8b43cee050d0@mail.gmail.com>

On Thu, Jul 3, 2008 at 8:45 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/7/3 Fred Drake <fdrake at acm.org>:
>
>> The "while <expr> as <var>:" 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>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
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>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
Message-ID: <873amqevvd.fsf@physik.rwth-aachen.de>

Hall?chen!

Facundo Batista writes:

> 2008/7/3 Stavros Korokithakis
> <stavros at korokithakis.net>:
>
>> 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: <e04bdf310807030845o1edc9751hd91048851682e740@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>
	<486CEE63.8050800@korokithakis.net>
	<057E8E37-60FE-4B1A-B653-AF953CCDD574@acm.org>
	<e04bdf310807030845o1edc9751hd91048851682e740@mail.gmail.com>
Message-ID: <bbaeab100807031046k2bb2fd4auab346fe80faa46b9@mail.gmail.com>

On Thu, Jul 3, 2008 at 8:45 AM, Facundo Batista
<facundobatista at gmail.com> wrote:
> 2008/7/3 Fred Drake <fdrake at acm.org>:
>
>> The "while <expr> as <var>:" 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>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
	<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   <fdrake at acm.org>






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>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
	<873amqevvd.fsf@physik.rwth-aachen.de>
Message-ID: <cc7430500807031057n3a4d32d0k8d7d1ccae432196d@mail.gmail.com>

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: <cf5b87740807031104x465612e6ndfb0a47b2324cfe9@mail.gmail.com>

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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/8e3a84ff/attachment.html>

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: <e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
Message-ID: <9bfc700a0807031209m73547e5eyf1b09f0f6894cfe5@mail.gmail.com>

2008/7/3 Facundo Batista <facundobatista at gmail.com>:
> 2008/7/3 Stavros Korokithakis <stavros at korokithakis.net>:
>
>> 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: <e04bdf310807030822j1ab94215wbf18943c8372d5bc@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>	<91ad5bf80807030755y1b582285l43985d63b3e217b1@mail.gmail.com>
	<e04bdf310807030822j1ab94215wbf18943c8372d5bc@mail.gmail.com>
Message-ID: <g4j9ei$ahf$1@ger.gmane.org>



Facundo Batista wrote:
> 2008/7/3 George Sakkis <george.sakkis at gmail.com>:
> 
>> 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 <expression> as <name>' 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>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
	<873amqevvd.fsf@physik.rwth-aachen.de>
Message-ID: <d11dcfba0807031315i42e0ec85ycb65108a60edce79@mail.gmail.com>

On Thu, Jul 3, 2008 at 11:11 AM, Torsten Bronger
<bronger at physik.rwth-aachen.de> wrote:
>> 2008/7/3 Stavros Korokithakis
>> <stavros at korokithakis.net>:
>>
>>> 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: <d11dcfba0807031315i42e0ec85ycb65108a60edce79@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>	<873amqevvd.fsf@physik.rwth-aachen.de>
	<d11dcfba0807031315i42e0ec85ycb65108a60edce79@mail.gmail.com>
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:

<setup>
while <expression>"
     <stuff>
     <setup>

Stavros

Steven Bethard wrote:
> On Thu, Jul 3, 2008 at 11:11 AM, Torsten Bronger
> <bronger at physik.rwth-aachen.de> wrote:
>>> 2008/7/3 Stavros Korokithakis
>>> <stavros at korokithakis.net>:
>>>
>>>> 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/cfaf9662/attachment.vcf>

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>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
	<873amqevvd.fsf@physik.rwth-aachen.de>
	<d11dcfba0807031315i42e0ec85ycb65108a60edce79@mail.gmail.com>
	<486D3520.9010406@korokithakis.net>
Message-ID: <d11dcfba0807031329t22fde8bck94d9d821e46d243d@mail.gmail.com>

On Thu, Jul 3, 2008 at 2: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:
>
> <setup>
> while <expression>"
>    <stuff>
>    <setup>

The "while True" concept "snuck in" because many of us write this idiom as::

    while True:
        <setup>
        if not <expression>:
            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>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
	<873amqevvd.fsf@physik.rwth-aachen.de>
	<d11dcfba0807031315i42e0ec85ycb65108a60edce79@mail.gmail.com>
	<486D3520.9010406@korokithakis.net>
Message-ID: <47c890dc0807031330j61954ed5g12531a5c18078bc9@mail.gmail.com>

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:
>
> <setup>
> while <expression>"
>    <stuff>
>    <setup>

And "while True" is the currently accepted idiom to replace that,
which possibly makes "while as" unnecessary.

while True:
    <setup>
    if not <expression>: break
    <stuff>

Note that <setup> is no longer repeated.

- Chris

>
> Stavros
>
> Steven Bethard wrote:
>>
>> On Thu, Jul 3, 2008 at 11:11 AM, Torsten Bronger
>> <bronger at physik.rwth-aachen.de> wrote:
>>>>
>>>> 2008/7/3 Stavros Korokithakis
>>>> <stavros at korokithakis.net>:
>>>>
>>>>> 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>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
	<873amqevvd.fsf@physik.rwth-aachen.de>
	<d11dcfba0807031315i42e0ec85ycb65108a60edce79@mail.gmail.com>
	<486D3520.9010406@korokithakis.net>
Message-ID: <cf5b87740807031334ka0f1e76v46a7e8f9cfe41313@mail.gmail.com>

And it doesn't do that! It only replaces that when <setup> is a simple
assignment.

PEP 315 suggested:

  do:
    <setup>
  while <expression>:
    <stuff>

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:
>
> <setup>
> while <expression>"
>    <stuff>
>    <setup>
>
> Stavros
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20080703/114d62cb/attachment.html>

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: <cf5b87740807031334ka0f1e76v46a7e8f9cfe41313@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>
	<e04bdf310807030746h555e76f9ha3d81a5723eb6a29@mail.gmail.com>
	<873amqevvd.fsf@physik.rwth-aachen.de>
	<d11dcfba0807031315i42e0ec85ycb65108a60edce79@mail.gmail.com>
	<486D3520.9010406@korokithakis.net>
	<cf5b87740807031334ka0f1e76v46a7e8f9cfe41313@mail.gmail.com>
Message-ID: <47c890dc0807031339t7027dd9v4329b6cd32d2bfcf@mail.gmail.com>

On Thu, Jul 3, 2008 at 1:34 PM, Bruce Leban <bruce at leapyear.org> wrote:
> And it doesn't do that! It only replaces that when <setup> is a simple
> assignment.
>
> PEP 315 suggested:
>
>   do:
>     <setup>
>   while <expression>:
>     <stuff>
>
> which does cover the general scenario.

The "while as" proposal is even less general. It only covers
single-statement assignment <setup>s.
And do multiline <setup>s really come up that often? Not in my
experience at least.

- Chris

>
>
> 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:
>>
>> <setup>
>> while <expression>"
>>    <stuff>
>>    <setup>
>>
>> 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 <tom at vector-seven.com> 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 <bjourne at gmail.com> wrote:
> On Thu, Jul 3, 2008 at 2:58 PM, Thomas Lee <tom at vector-seven.com> 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 <mwm at mired.org> 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: <D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>

From: "BJ?rn Lindqvist" <bjourne at gmail.com>
>  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: <D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>
References: <486CDCF5.6080805@korokithakis.net><486CE075.3000104@vector-seven.com>
	<486CE11F.50601@korokithakis.net><486CE904.2040403@vector-seven.com>
	<740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com>
	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>
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 <expr>: ..." syntax better.


   -Fred

-- 
Fred Drake   <fdrake at acm.org>






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>
	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>
	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>
Message-ID: <ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>

On Thu, Jul 3, 2008 at 8:21 PM, Fred Drake <fdrake at acm.org> 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 <expr>: ..." 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 <setup> 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 = <expr>) > 0 && (y = <expr>) < 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: <ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@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>
	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>
	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>
	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>
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: <D73A5A3D-4AFE-4063-BC88-C294E7187BB2@gmail.com>


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: <g4oq9q$aqi$1@ger.gmane.org>



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: <g4oq9q$aqi$1@ger.gmane.org>
References: <486F9710.6060602@onego.ru> <g4oq9q$aqi$1@ger.gmane.org>
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: <D73A5A3D-4AFE-4063-BC88-C294E7187BB2@gmail.com>
References: <486F9710.6060602@onego.ru>
	<D73A5A3D-4AFE-4063-BC88-C294E7187BB2@gmail.com>
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> <g4oq9q$aqi$1@ger.gmane.org>
	<48706E12.3010702@onego.ru>
Message-ID: <ca471dc20807071005j1e372535q49630170e0656354@mail.gmail.com>

On Sun, Jul 6, 2008 at 12:02 AM, Roman Susi <rnd at onego.ru> 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: <ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@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>	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>
	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>
Message-ID: <4872CCA9.1040908@acm.org>

Guido van Rossum wrote:
> On Thu, Jul 3, 2008 at 8:21 PM, Fred Drake <fdrake at acm.org> 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 <expr>: ..." 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 <setup> 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>
	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>
	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>
	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>
	<4872CCA9.1040908@acm.org>
Message-ID: <ca471dc20807072108s55a6d389h2b61bf65d0dc8676@mail.gmail.com>

On Mon, Jul 7, 2008 at 7:10 PM, Talin <talin at acm.org> 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>	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>
	<4872CCA9.1040908@acm.org>
Message-ID: <g50at9$b5m$1@ger.gmane.org>



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 <re_x> 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: <g50at9$b5m$1@ger.gmane.org>
References: <486CDCF5.6080805@korokithakis.net>
	<486CE075.3000104@vector-seven.com> <486CE11F.50601@korokithakis.net>
	<486CE904.2040403@vector-seven.com>
	<740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com>
	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>
	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>
	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>
	<4872CCA9.1040908@acm.org> <g50at9$b5m$1@ger.gmane.org>
Message-ID: <c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>

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 <tjreedy at udel.edu> 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 <re_x> 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080709/4f63e540/attachment.html>

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: <g50at9$b5m$1@ger.gmane.org>
References: <486CDCF5.6080805@korokithakis.net>	<486CE075.3000104@vector-seven.com>	<486CE11F.50601@korokithakis.net>	<486CE904.2040403@vector-seven.com>	<740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com>	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>	<4872CCA9.1040908@acm.org>
	<g50at9$b5m$1@ger.gmane.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 <re_x> 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: <g52tdt$ehl$2@ger.gmane.org>



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: <c7450fba0807090442t6a6213ald670b71bcca2b3fb@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>
	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>
	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>
	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>
	<4872CCA9.1040908@acm.org> <g50at9$b5m$1@ger.gmane.org>
	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>
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>
	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>
	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>
	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>
	<4872CCA9.1040908@acm.org> <g50at9$b5m$1@ger.gmane.org>
	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>
	<487550DE.50309@canterbury.ac.nz>
Message-ID: <c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>

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 <greg.ewing at canterbury.ac.nz>
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: <http://mail.python.org/pipermail/python-ideas/attachments/20080711/29c638ee/attachment.html>

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: <c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>
	<740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com>
	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>
	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>
	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>
	<4872CCA9.1040908@acm.org> <g50at9$b5m$1@ger.gmane.org>
	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>
	<487550DE.50309@canterbury.ac.nz>
	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>
Message-ID: <e6511dbf0807110959s4d34acb3sbc471fe5fd064501@mail.gmail.com>

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
<andrew at atoulou.se> 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 <greg.ewing at canterbury.ac.nz>
> 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: <ca471dc20807161257s2059f707rbbf9343ce1777e4f@mail.gmail.com>
References: <ca471dc20807161257s2059f707rbbf9343ce1777e4f@mail.gmail.com>
Message-ID: <ca471dc20807171022u70b76960vf6e47b3d22efbce8@mail.gmail.com>

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: <ca471dc20807171022u70b76960vf6e47b3d22efbce8@mail.gmail.com>
References: <ca471dc20807161257s2059f707rbbf9343ce1777e4f@mail.gmail.com>
	<ca471dc20807171022u70b76960vf6e47b3d22efbce8@mail.gmail.com>
Message-ID: <E4FBCF6D-EF94-4E2A-BFE3-0648E1DC14E4@acm.org>

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   <fdrake at acm.org>






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: <g5plid$tsm$1@ger.gmane.org>

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: <c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>	<486CE904.2040403@vector-seven.com>	<740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com>	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>	<4872CCA9.1040908@acm.org>
	<g50at9$b5m$1@ger.gmane.org>	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>	<487550DE.50309@canterbury.ac.nz>
	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>
Message-ID: <g6lt76$q75$1@ger.gmane.org>

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: <g6lt76$q75$1@ger.gmane.org>
References: <486CDCF5.6080805@korokithakis.net>	<486CE904.2040403@vector-seven.com>	<740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com>	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>	<4872CCA9.1040908@acm.org>	<g50at9$b5m$1@ger.gmane.org>	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>	<487550DE.50309@canterbury.ac.nz>	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>
	<g6lt76$q75$1@ger.gmane.org>
Message-ID: <g6mnpl$r1n$1@ger.gmane.org>



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: <g6lt76$q75$1@ger.gmane.org>
References: <486CDCF5.6080805@korokithakis.net>	<486CE904.2040403@vector-seven.com>	<740c3aec0807031353g23d00279x5f797750b1f5f9d8@mail.gmail.com>	<D3C8B31F6E824022874BAB01C78D2407@RaymondLaptop1>	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>	<4872CCA9.1040908@acm.org>	<g50at9$b5m$1@ger.gmane.org>	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>	<487550DE.50309@canterbury.ac.nz>	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>
	<g6lt76$q75$1@ger.gmane.org>
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>
	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>
	<4872CCA9.1040908@acm.org> <g50at9$b5m$1@ger.gmane.org>
	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>
	<487550DE.50309@canterbury.ac.nz>
	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>
	<g6lt76$q75$1@ger.gmane.org> <488EEDCC.7050303@onego.ru>
Message-ID: <c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>

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 <rnd at onego.ru> 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080729/947196c6/attachment.html>

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: <c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>	<4872CCA9.1040908@acm.org>
	<g50at9$b5m$1@ger.gmane.org>	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>	<487550DE.50309@canterbury.ac.nz>	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>	<g6lt76$q75$1@ger.gmane.org>
	<488EEDCC.7050303@onego.ru>
	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>
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 <rnd at onego.ru 
> <mailto:rnd at onego.ru>> 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 <mailto:Python-ideas at python.org>
>      > http://mail.python.org/mailman/listinfo/python-ideas
>      >
>      > !DSPAM:488e7c4d23202007710671!
>      >
> 
>     _______________________________________________
>     Python-ideas mailing list
>     Python-ideas at python.org <mailto: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: <c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>	
	<088C35D1-D1B9-4A39-B004-F9C06B29E7AC@acm.org>	
	<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>	
	<4872CCA9.1040908@acm.org> <g50at9$b5m$1@ger.gmane.org>	
	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>	
	<487550DE.50309@canterbury.ac.nz>	
	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>	
	<g6lt76$q75$1@ger.gmane.org> <488EEDCC.7050303@onego.ru>
	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>
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 <rnd at onego.ru
> <mailto:rnd at onego.ru>> 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 <mailto:Python-ideas at python.org>
>     > http://mail.python.org/mailman/listinfo/python-ideas
>     >
>     >
>     >
> 
>     _______________________________________________
>     Python-ideas mailing list
>     Python-ideas at python.org <mailto: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>		<ca471dc20807032033n319ae95fi2967dd2e0aaf1b59@mail.gmail.com>		<4872CCA9.1040908@acm.org>
	<g50at9$b5m$1@ger.gmane.org>		<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>		<487550DE.50309@canterbury.ac.nz>		<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>		<g6lt76$q75$1@ger.gmane.org>
	<488EEDCC.7050303@onego.ru>	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>
	<488F64A7.9010902@onego.ru>
Message-ID: <g6o1g5$h5h$1@ger.gmane.org>



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: <g6o1g5$h5h$1@ger.gmane.org>
References: <486CDCF5.6080805@korokithakis.net> <g50at9$b5m$1@ger.gmane.org>
	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>
	<487550DE.50309@canterbury.ac.nz>
	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>
	<g6lt76$q75$1@ger.gmane.org> <488EEDCC.7050303@onego.ru>
	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>
	<488F64A7.9010902@onego.ru> <g6o1g5$h5h$1@ger.gmane.org>
Message-ID: <d11dcfba0807291504w43eb06cfvb68b1709d606302f@mail.gmail.com>

On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy <tjreedy at udel.edu> 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: <d11dcfba0807291504w43eb06cfvb68b1709d606302f@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>
	<g50at9$b5m$1@ger.gmane.org>	<c7450fba0807090442t6a6213ald670b71bcca2b3fb@mail.gmail.com>	<487550DE.50309@canterbury.ac.nz>	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>	<g6lt76$q75$1@ger.gmane.org>
	<488EEDCC.7050303@onego.ru>	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>	<488F64A7.9010902@onego.ru>
	<g6o1g5$h5h$1@ger.gmane.org>
	<d11dcfba0807291504w43eb06cfvb68b1709d606302f@mail.gmail.com>
Message-ID: <g6ol7o$215$1@ger.gmane.org>



Steven Bethard wrote:
> On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy <tjreedy at udel.edu> 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: <g6ol7o$215$1@ger.gmane.org>
References: <486CDCF5.6080805@korokithakis.net>
	<487550DE.50309@canterbury.ac.nz>
	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>
	<g6lt76$q75$1@ger.gmane.org> <488EEDCC.7050303@onego.ru>
	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>
	<488F64A7.9010902@onego.ru> <g6o1g5$h5h$1@ger.gmane.org>
	<d11dcfba0807291504w43eb06cfvb68b1709d606302f@mail.gmail.com>
	<g6ol7o$215$1@ger.gmane.org>
Message-ID: <d11dcfba0807292229q3b2dfc0r3d3a4e5bf1824068@mail.gmail.com>

On Tue, Jul 29, 2008 at 8:55 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Steven Bethard wrote:
>> On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy <tjreedy at udel.edu> 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(<expression with x>)
        return _1
    return _(seq)

    def _(seq):
        for x in seq:
            yield <expression with x>
    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: <d11dcfba0807292229q3b2dfc0r3d3a4e5bf1824068@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>	<487550DE.50309@canterbury.ac.nz>	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>	<g6lt76$q75$1@ger.gmane.org>
	<488EEDCC.7050303@onego.ru>	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>	<488F64A7.9010902@onego.ru>
	<g6o1g5$h5h$1@ger.gmane.org>	<d11dcfba0807291504w43eb06cfvb68b1709d606302f@mail.gmail.com>	<g6ol7o$215$1@ger.gmane.org>
	<d11dcfba0807292229q3b2dfc0r3d3a4e5bf1824068@mail.gmail.com>
Message-ID: <48900977.6050703@onego.ru>

Steven Bethard wrote:
> On Tue, Jul 29, 2008 at 8:55 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> Steven Bethard wrote:
>>> On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy <tjreedy at udel.edu> 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(<expression with x>)
>         return _1
>     return _(seq)
> 
>     def _(seq):
>         for x in seq:
>             yield <expression with x>
>     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: <d11dcfba0807292229q3b2dfc0r3d3a4e5bf1824068@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net>	<487550DE.50309@canterbury.ac.nz>	<c7450fba0807110210n54842ed4yb5adca90938b5eb3@mail.gmail.com>	<g6lt76$q75$1@ger.gmane.org>
	<488EEDCC.7050303@onego.ru>	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>	<488F64A7.9010902@onego.ru>
	<g6o1g5$h5h$1@ger.gmane.org>	<d11dcfba0807291504w43eb06cfvb68b1709d606302f@mail.gmail.com>	<g6ol7o$215$1@ger.gmane.org>
	<d11dcfba0807292229q3b2dfc0r3d3a4e5bf1824068@mail.gmail.com>
Message-ID: <g6pvmu$10v$1@ger.gmane.org>



Steven Bethard wrote:
> On Tue, Jul 29, 2008 at 8:55 PM, Terry Reedy <tjreedy at udel.edu> wrote:
>> Steven Bethard wrote:
>>> On Tue, Jul 29, 2008 at 3:19 PM, Terry Reedy <tjreedy at udel.edu> 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(<expression with x>)
>         return _1
>     return _(seq)
> 
>     def _(seq):
>         for x in seq:
>             yield <expression with x>
>     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: <g6pvmu$10v$1@ger.gmane.org>
References: <486CDCF5.6080805@korokithakis.net> <g6lt76$q75$1@ger.gmane.org>
	<488EEDCC.7050303@onego.ru>
	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>
	<488F64A7.9010902@onego.ru> <g6o1g5$h5h$1@ger.gmane.org>
	<d11dcfba0807291504w43eb06cfvb68b1709d606302f@mail.gmail.com>
	<g6ol7o$215$1@ger.gmane.org>
	<d11dcfba0807292229q3b2dfc0r3d3a4e5bf1824068@mail.gmail.com>
	<g6pvmu$10v$1@ger.gmane.org>
Message-ID: <d11dcfba0807300926r26dd02d4oef57edefd3afc4cb@mail.gmail.com>

On Wed, Jul 30, 2008 at 9:00 AM, Terry Reedy <tjreedy at udel.edu> 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(<genexp>) is the same as [<listcomp>].

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: <d11dcfba0807300926r26dd02d4oef57edefd3afc4cb@mail.gmail.com>
References: <486CDCF5.6080805@korokithakis.net> <488EEDCC.7050303@onego.ru>
	<c7450fba0807290955y57437896wca3ad1b037ad824d@mail.gmail.com>
	<488F64A7.9010902@onego.ru> <g6o1g5$h5h$1@ger.gmane.org>
	<d11dcfba0807291504w43eb06cfvb68b1709d606302f@mail.gmail.com>
	<g6ol7o$215$1@ger.gmane.org>
	<d11dcfba0807292229q3b2dfc0r3d3a4e5bf1824068@mail.gmail.com>
	<g6pvmu$10v$1@ger.gmane.org>
	<d11dcfba0807300926r26dd02d4oef57edefd3afc4cb@mail.gmail.com>
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 <steven.bethard at gmail.com>wrote:

> On Wed, Jul 30, 2008 at 9:00 AM, Terry Reedy <tjreedy at udel.edu> 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(<genexp>) is the same as [<listcomp>].
>
> 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: <http://mail.python.org/pipermail/python-ideas/attachments/20080730/0f4da25e/attachment.html>