The PEP is deferred because it seems that while True: <code> if condition: break is good enough. I agree. We should reject the PEP and summarise the status. Alternatively, the only way I think we can improve on the syntax above is something like this: do: <code> if condition: break or without a new keyword: while: <code> if condition: break The empty-predicate variant would let Python check whether there's actually a break in the body of the loop. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev
Łukasz Langa wrote: Alternatively, the only way I think we can improve on
the syntax above is something like this:
do: <code> if condition: break
One of the problems with a 'while' clause as suggested is that the comprehension version of it would complicate the equivalence rules between comprehensions and statements. Currently, a comprehension such as [... for a in x if c] corresponds to for a in x: if c: ... But if we take a comprehension with a 'while' clause, [... for a in x while c] and try to expand it the same way, we get for a in x: while c: ... which is not the same thing at all! To make it work, we need to expand it as for a in x: if not c: break But this only works if there is only one for-loop. If we have two nested loops, [... for a in x for b in y while c] the following expansion doesn't work, for a in x: for b in y: if not c: break because the break only exits the innermost loop. The proposed 'while' clause has a similar problem. In for a in x: for b in y while c: ... the 'while' would presumably break only the innermost loop. If we try to write it like this instead, for a in x while c: for b in y: ... we have a problem if the condition c involves both a and b. I'm not sure what the lesson is from all this. I think it's that any form of early-exit construct, including 'break' and the proposed 'while' clause, is a hack of limited usefulness without some way of scoping the amount of stuff to be broken out of. Comprehensions provide a natural way of specifying that scope, whereas the looping statements don't. So, I would probably support adding a 'while' clause to comprehensions, but not to the for-loop statement. -- Greg
On 26 cze 2013, at 11:24, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Łukasz Langa wrote: Alternatively, the only way I think we can improve on
the syntax above is something like this: do: <code> if condition: break
But if we take a comprehension with a 'while' clause,
[... for a in x while c]
Correct me if I'm wrong but it seems you mixed up two independent threads on the list. I'm discussing an equivalent of the C `do {} while();` loop. This doesn't touch comprehensions at all. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev
Please reject the PEP. More variations along these lines won't make the language more elegant or easier to learn. They'd just save a few hasty folks some typing while making others who have to read/maintain their code wonder what it means. --Guido On Wed, Jun 26, 2013 at 1:47 AM, Łukasz Langa <lukasz@langa.pl> wrote:
The PEP is deferred because it seems that
while True: <code> if condition: break
is good enough. I agree. We should reject the PEP and summarise the status. Alternatively, the only way I think we can improve on the syntax above is something like this:
do: <code> if condition: break
or without a new keyword:
while: <code> if condition: break
The empty-predicate variant would let Python check whether there's actually a break in the body of the loop.
-- Best regards, Łukasz Langa
WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
On 26 cze 2013, at 17:03, Guido van Rossum <guido@python.org> wrote:
Please reject the PEP. More variations along these lines won't make the language more elegant or easier to learn. They'd just save a few hasty folks some typing while making others who have to read/maintain their code wonder what it means.
Done. PEP 315 has been rejected. http://hg.python.org/peps/rev/21deefe50c51 -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev
Just to clarify, PEP 315 had to do with a do-while concept (to make common use of pre-while code that often exists) and not the (dubious) issue of: for X in listY while conditionZ: or for X in listY and conditionZ: (fwhile) Right? There seemed to be some confusion, but maybe they are related, but I'm not sure how.... -Jim -----Original Message----- From: Łukasz Langa <lukasz@langa.pl> To: Guido van Rossum <guido@python.org> Cc: Python-Ideas <python-ideas@python.org> Sent: Wed, Jun 26, 2013 11:40 am Subject: Re: [Python-ideas] PEP 315: do-while On 26 cze 2013, at 17:03, Guido van Rossum <guido@python.org> wrote: Please reject the PEP. More variations along these lines won't make the language more elegant or easier to learn. They'd just save a few hasty folks some typing while making others who have to read/maintain their code wonder what it means. Done. PEP 315 has been rejected. http://hg.python.org/peps/rev/21deefe50c51 -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
FWIW I'm against adding anything along these lines (the motivation is the same as what I wrote before). On Wed, Jun 26, 2013 at 1:25 PM, <jimjhb@aol.com> wrote:
Just to clarify, PEP 315 had to do with a do-while concept (to make common use of pre-while code that often exists) and not the (dubious) issue of:
for X in listY while conditionZ:
or
for X in listY and conditionZ:
(fwhile)
Right?
There seemed to be some confusion, but maybe they are related, but I'm not sure how....
-Jim
-----Original Message----- From: Łukasz Langa <lukasz@langa.pl> To: Guido van Rossum <guido@python.org> Cc: Python-Ideas <python-ideas@python.org> Sent: Wed, Jun 26, 2013 11:40 am Subject: Re: [Python-ideas] PEP 315: do-while
On 26 cze 2013, at 17:03, Guido van Rossum <guido@python.org> wrote:
Please reject the PEP. More variations along these lines won't make the language more elegant or easier to learn. They'd just save a few hasty folks some typing while making others who have to read/maintain their code wonder what it means.
Done. PEP 315 has been rejected.
http://hg.python.org/peps/rev/21deefe50c51
-- Best regards, Łukasz Langa
WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
Sounds good to me. Just let people know it's OK to use breaks!!! MISRA-C 1998 (I know it's C, but people extrapolated that to other languages) banned continues and breaks. MISRA-C 2004 allowed for one break in a loop. But by that point the damage had been done. Now there are lots of folks out there that have been trained to NOT use break and continue (ever), even in Python. So the notion was an attempt to deal with that perhaps unreasonable, but still actual, reality. -Jim -----Original Message----- From: Guido van Rossum <guido@python.org> To: jimjhb <jimjhb@aol.com> Cc: lukasz <lukasz@langa.pl>; python-ideas <python-ideas@python.org> Sent: Wed, Jun 26, 2013 4:41 pm Subject: Re: [Python-ideas] PEP 315: do-while FWIW I'm against adding anything along these lines (the motivation is the same as what I wrote before). On Wed, Jun 26, 2013 at 1:25 PM, <jimjhb@aol.com> wrote:
Just to clarify, PEP 315 had to do with a do-while concept (to make common use of pre-while code that often exists) and not the (dubious) issue of:
for X in listY while conditionZ:
or
for X in listY and conditionZ:
(fwhile)
Right?
There seemed to be some confusion, but maybe they are related, but I'm not sure how....
-Jim
-----Original Message----- From: Łukasz Langa <lukasz@langa.pl> To: Guido van Rossum <guido@python.org> Cc: Python-Ideas <python-ideas@python.org> Sent: Wed, Jun 26, 2013 11:40 am Subject: Re: [Python-ideas] PEP 315: do-while
On 26 cze 2013, at 17:03, Guido van Rossum <guido@python.org> wrote:
Please reject the PEP. More variations along these lines won't make the language more elegant or easier to learn. They'd just save a few hasty folks some typing while making others who have to read/maintain their code wonder what it means.
Done. PEP 315 has been rejected.
http://hg.python.org/peps/rev/21deefe50c51
-- Best regards, Łukasz Langa
WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
What misery. :-) --Guido van Rossum (sent from Android phone) On Jun 26, 2013 1:48 PM, <jimjhb@aol.com> wrote:
Sounds good to me. Just let people know it's OK to use breaks!!!
MISRA-C 1998 (I know it's C, but people extrapolated that to other languages) banned continues and breaks. MISRA-C 2004 allowed for one break in a loop.
But by that point the damage had been done. Now there are lots of folks out there that have been trained to NOT use break and continue (ever), even in Python.
So the notion was an attempt to deal with that perhaps unreasonable, but still actual, reality.
-Jim
-----Original Message----- From: Guido van Rossum <guido@python.org> To: jimjhb <jimjhb@aol.com> Cc: lukasz <lukasz@langa.pl>; python-ideas <python-ideas@python.org> Sent: Wed, Jun 26, 2013 4:41 pm Subject: Re: [Python-ideas] PEP 315: do-while
FWIW I'm against adding anything along these lines (the motivation is the same as what I wrote before).
On Wed, Jun 26, 2013 at 1:25 PM, <jimjhb@aol.com> wrote:
Just to clarify, PEP 315 had to do with a do-while concept (to make common use of pre-while code that often exists) and not the (dubious) issue of:
for X in listY while conditionZ:
or
for X in listY and conditionZ:
(fwhile)
Right?
There seemed to be some confusion, but maybe they are related, but I'm not sure how....
-Jim
-----Original Message----- From: Łukasz Langa <lukasz@langa.pl> To: Guido van Rossum <guido@python.org> Cc: Python-Ideas <python-ideas@python.org> Sent: Wed, Jun 26, 2013 11:40 am Subject: Re: [Python-ideas] PEP 315: do-while
On 26 cze 2013, at 17:03, Guido van Rossum <guido@python.org> wrote:
Please reject the PEP. More variations along these lines won't make the language more elegant or easier to learn. They'd just save a few hasty folks some typing while making others who have to read/maintain their code wonder what it means.
Done. PEP 315 has been rejected.
http://hg.python.org/peps/rev/21deefe50c51
-- Best regards, Łukasz Langa
WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
From: "jimjhb@aol.com" <jimjhb@aol.com> Sent: Wednesday, June 26, 2013 1:48 PM
Sounds good to me. Just let people know it's OK to use breaks!!!
MISRA-C 1998 (I know it's C, but people extrapolated that to other languages) banned continues and breaks. MISRA-C 2004 allowed for one break in a loop.
In case it's not obvious how ridiculous it is to extrapolate MISRA-C to other languages… I went through the 127 rules in MISRA-C 1998. About 52 of them could be extrapolated to Python. Of those, 20 make some sense; the other 32 would be either ridiculous or disastrous to apply in Python. (In fact, much the same is true even for more closely-related languages like C++ or JavaScript.) If you're curious about the details, see http://stupidpythonideas.blogspot.com/2013/06/misra-c-and-python.html.
On 27 June 2013 00:17, Andrew Barnert <abarnert@yahoo.com> wrote:
In case it's not obvious how ridiculous it is to extrapolate MISRA-C to other languages…
I went through the 127 rules in MISRA-C 1998. About 52 of them could be extrapolated to Python. Of those, 20 make some sense; the other 32 would be either ridiculous or disastrous to apply in Python. (In fact, much the same is true even for more closely-related languages like C++ or JavaScript.)
If you're curious about the details, see http://stupidpythonideas.blogspot.com/2013/06/misra-c-and-python.html.
"67. rcm: Don't rebind the iterator in a for loop." That sounds quite sane to me...
On 06/26/2013 04:25 PM, Joshua Landau wrote:
On 27 June 2013 00:17, Andrew Barnert <abarnert@yahoo.com> wrote:
In case it's not obvious how ridiculous it is to extrapolate MISRA-C to other languages…
I went through the 127 rules in MISRA-C 1998. About 52 of them could be extrapolated to Python. Of those, 20 make some sense; the other 32 would be either ridiculous or disastrous to apply in Python. (In fact, much the same is true even for more closely-related languages like C++ or JavaScript.)
If you're curious about the details, see http://stupidpythonideas.blogspot.com/2013/06/misra-c-and-python.html.
"67. rcm: Don't rebind the iterator in a for loop."
That sounds quite sane to me...
def NameCase(*names): '''names should already be stripped of whitespace''' if not any(names): return names final = [] for name in names: pieces = name.lower().split() result = [] for i, piece in enumerate(pieces): if '-' in piece: piece = ' '.join(piece.replace('-',' ').split()) piece = '-'.join(NameCase(piece).split()) elif alpha_num(piece) in ('i', 'ii', 'iii', 'iv', 'v', 'vi', 'vii', 'viii', 'ix', 'x'): piece = piece.upper() elif piece in ('and', 'de', 'del', 'der', 'el', 'la', 'van', 'of'): pass elif piece[:2] == 'mc': piece = 'Mc' + piece[2:].title() else: possible = mixed_case_names.get(piece, None) if possible is not None: piece = possible else: piece = piece.title() if piece[-2:].startswith("'"): piece = piece[:-1] + piece[-1].lower() result.append(piece) if result[0] == result[0].lower(): result[0] = result[0].title() if result[-1] == result[-1].lower(): result[-1] = result[-1].title() final.append(' '.join(result)) return final -- ~Ethan~
On Jun 26, 2013, at 16:25, Joshua Landau <joshua.landau.ws@gmail.com> wrote:
On 27 June 2013 00:17, Andrew Barnert <abarnert@yahoo.com> wrote:
In case it's not obvious how ridiculous it is to extrapolate MISRA-C to other languages…
I went through the 127 rules in MISRA-C 1998. About 52 of them could be extrapolated to Python. Of those, 20 make some sense; the other 32 would be either ridiculous or disastrous to apply in Python. (In fact, much the same is true even for more closely-related languages like C++ or JavaScript.)
If you're curious about the details, see http://stupidpythonideas.blogspot.com/2013/06/misra-c-and-python.html.
"67. rcm: Don't rebind the iterator in a for loop."
That sounds quite sane to me...
Why? In C, the loop iterator is a mutable variable; assigning to it changes the loop flow. for (i=0; i!=10; ++i) { if (i % 2) { i = 0; } printf("%d\n", i); } That looks like it should alternate even numbers with 0's, up to 10. But it actually produces an infinite loop of 0's. Very confusing. In Python, the loop iterator is just a name for a value; assigning to it does not change that value or affect the flow in any way; it just gives you a convenient name for a different value. for i in range(10): if i % 2: i = 0 print i That looks like it should alternate even numbers with 0's, up to 10. And that's exactly what it does. Obviously this is a silly toy example, but there's plenty of real code that does this kind of thing.
On 27 June 2013 03:41, Andrew Barnert <abarnert@yahoo.com> wrote:
On Jun 26, 2013, at 16:25, Joshua Landau <joshua.landau.ws@gmail.com> wrote:
On 27 June 2013 00:17, Andrew Barnert <abarnert@yahoo.com> wrote:
In case it's not obvious how ridiculous it is to extrapolate MISRA-C to other languages…
I went through the 127 rules in MISRA-C 1998. About 52 of them could be extrapolated to Python. Of those, 20 make some sense; the other 32 would be either ridiculous or disastrous to apply in Python. (In fact, much the same is true even for more closely-related languages like C++ or JavaScript.)
If you're curious about the details, see http://stupidpythonideas.blogspot.com/2013/06/misra-c-and-python.html.
"67. rcm: Don't rebind the iterator in a for loop."
That sounds quite sane to me...
Why?
In C, the loop iterator is a mutable variable; assigning to it changes the loop flow.
for (i=0; i!=10; ++i) { if (i % 2) { i = 0; } printf("%d\n", i); }
That looks like it should alternate even numbers with 0's, up to 10. But it actually produces an infinite loop of 0's. Very confusing.
In Python, the loop iterator is just a name for a value; assigning to it does not change that value or affect the flow in any way; it just gives you a convenient name for a different value.
for i in range(10): if i % 2: i = 0 print i
That looks like it should alternate even numbers with 0's, up to 10. And that's exactly what it does.
Obviously this is a silly toy example, but there's plenty of real code that does this kind of thing.
My response applies to Ethan as well; it'll be pointless to post it twice. You are not rebinding the *iterator* but the, um, iteree? Rebinding the iterator, to me, would look more like:
looper = range(10) for value in looper: ... looper = range(value-2) ... print(value, end="") ... 0123456789
Which is just a confusing thing to do, or (even worse):
looper = list(range(10)) for value in looper: ... looper.append(value) ... print(value, end="") ... 01234567890123456789012345678901234567890123456...
Which can be very bad if you do it on hashed things (when you could), and is really quite confusing. There are so very few reasons to do this that "just avoid it" is a good response, á mon avis.
(You have an extra period on your link....) Andrew, I'm not doubting what you are saying, but I am informing the python community of the reality out there. Say what you will, but Python's lack of gotos (if they are bad, then one can just avoid them, right?) is a form of social engineering on Python's part as well. I think that's a good decision, but one can see how social engineering of programmers can go awry as well. (MISRA-C 2012 now allows for limited gotos, so times change.) If I take the viewpoint of the no break/continue folks, they have a point. They can often be avoided, and throwing them in (a lot) is often a sign of sloppy code. Breaks (especially) are very easy to avoid with the C for, because the conditional is explicit and can easily be expanded. So for C, educating folks with these rules don't really have much net effect. The PROBLEM is that you can't do that with a Python for. So all this rule indoctrination is much more consequential (to the code). If can argue that adding a conditional SHOULDN'T be necessary, but that might not reflect our current practical reality. -----Original Message----- From: Andrew Barnert <abarnert@yahoo.com> To: jimjhb <jimjhb@aol.com>; guido <guido@python.org> Cc: python-ideas <python-ideas@python.org> Sent: Wed, Jun 26, 2013 7:17 pm Subject: Re: [Python-ideas] PEP 315: do-while From: "jimjhb@aol.com" <jimjhb@aol.com> Sent: Wednesday, June 26, 2013 1:48 PM
Sounds good to me. Just let people know it's OK to use breaks!!!
MISRA-C 1998 (I know it's C, but people extrapolated that to other languages) banned continues and breaks. MISRA-C 2004 allowed for one break in a loop.
In case it's not obvious how ridiculous it is to extrapolate MISRA-C to other languages… I went through the 127 rules in MISRA-C 1998. About 52 of them could be extrapolated to Python. Of those, 20 make some sense; the other 32 would be either ridiculous or disastrous to apply in Python. (In fact, much the same is true even for more closely-related languages like C++ or JavaScript.) If you're curious about the details, see http://stupidpythonideas.blogspot.com/2013/06/misra-c-and-python.html.
On 27 June 2013 14:26, <jimjhb@aol.com> wrote:
Andrew,
I'm not doubting what you are saying, but I am informing the python community of the reality out there. Say what you will, but Python's lack of gotos (if they are bad, then one can just avoid them, right?) is a form of social engineering on Python's part as well. I think that's a good decision, but one can see how social engineering of programmers can go awry as well. (MISRA-C 2012 now allows for limited gotos, so times change.)
If I take the viewpoint of the no break/continue folks, they have a point. They can often be avoided, and throwing them in (a lot) is often a sign of sloppy code. Breaks (especially) are very easy to avoid with the C for, because the conditional is explicit and can easily be expanded. So for C, educating folks with these rules don't really have much net effect.
The PROBLEM is that you can't do that with a Python for. So all this rule indoctrination is much more consequential (to the code).
If can argue that adding a conditional SHOULDN'T be necessary, but that might not reflect our current practical reality.
As the rest of us have said, this is irrelevant. These people you know are not the norm and no-one is going to budge for them. That's it; and no matter how much you reiterate this is not going to convince even those people who like your suggestion (of which I am not one). Please, just let this point rest.
-----Original Message----- From: Joshua Landau <joshua.landau.ws@gmail.com> To: jimjhb <jimjhb@aol.com> Cc: Andrew Barnert <abarnert@yahoo.com>; python-ideas <python-ideas@python.org> Sent: Thu, Jun 27, 2013 9:35 am Subject: Re: [Python-ideas] PEP 315: do-while On 27 June 2013 14:26, <jimjhb@aol.com> wrote:
Andrew,
I'm not doubting what you are saying, but I am informing the python community of the reality out there. Say what you will, but Python's lack of gotos (if they are bad, then one can just avoid them, right?) is a form of social engineering on Python's part as well. I think that's a good decision, but one can see how social engineering of programmers can go awry as well. (MISRA-C 2012 now allows for limited gotos, so times change.)
If I take the viewpoint of the no break/continue folks, they have a point. They can often be avoided, and throwing them in (a lot) is often a sign of sloppy code. Breaks (especially) are very easy to avoid with the C for, because the conditional is explicit and can easily be expanded. So for C, educating folks with these rules don't really have much net effect.
The PROBLEM is that you can't do that with a Python for. So all this rule indoctrination is much more consequential (to the code).
If can argue that adding a conditional SHOULDN'T be necessary, but that might not reflect our current practical reality.
As the rest of us have said, this is irrelevant. These people you know are not the norm and no-one is going to budge for them. That's it; and no matter how much you reiterate this is not going to convince even those people who like your suggestion (of which I am not one). Please, just let this point rest. =================== Joshua, You make a good point. I have no idea how prevalent the problem really is, and that's obviously relevant. (I haven't taken any polls, and neither have you.) Bottom line is most other languages allow early termination of for loops without breaking out of them. Python does not.
On 06/27/2013 07:48 AM, jimjhb@aol.com wrote:
Bottom line is most other languages allow early termination of for loops without breaking out of them. Python does not.
If they are terminating early, then they most certainly are breaking out of them, regardless of whether the word 'break' is used. -- ~Ethan~
-----Original Message----- From: Ethan Furman <ethan@stoneleaf.us> To: python-ideas <python-ideas@python.org> Sent: Thu, Jun 27, 2013 12:43 pm Subject: Re: [Python-ideas] PEP 315: do-while On 06/27/2013 07:48 AM, jimjhb@aol.com wrote:
Bottom line is most other languages allow early termination of for loops without breaking out of them. Python does not.
If they are terminating early, then they most certainly are breaking out of them, regardless of whether the word 'break' is used. Yes, but the control flow (and location of the control) is different. All this "don't use breaks" stuff can be traced back to E.W Dijkstra and structured programming. Structured programming remains in a lot of mindsets today. -- ~Ethan~ _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
On Jun 27, 2013, at 9:53, jimjhb@aol.com wrote:
-----Original Message----- From: Ethan Furman <ethan@stoneleaf.us> To: python-ideas <python-ideas@python.org> Sent: Thu, Jun 27, 2013 12:43 pm Subject: Re: [Python-ideas] PEP 315: do-while
On 06/27/2013 07:48 AM, jimjhb@aol.com wrote:
Bottom line is most other languages allow early termination of for loops without breaking out of them. Python does not.
If they are terminating early, then they most certainly are breaking out of them, regardless of whether the word 'break' is used. Yes, but the control flow (and location of the control) is different. All this "don't use breaks" stuff can be traced back to E.W Dijkstra and structured programming. Structured programming remains in a lot of mindsets today. Structured programming is all about how to write maintainable programs in a low-level Algol-like language, and that's what C is. But that's not even close to what Python is. People trying to program Python as if it were C are going to write bad Python. Bending over backward to accommodate them will only make things worse.
The best thing we can do is use as many generators as possible--anyone who thinks break doesn't belong in Python will suffer from head-asplode once they finally realize what yield does to control flow, and then they'll no longer be a problem.
Opinions about break statements are really irrelevant, IMHO. The reason this idea hadn’t taken legs isn’t because of concern about abiding by educators’ blanket rules. List comprehensions are concise, intuitive, and efficient; proper use can improve readability *and* performance significantly. The number of proper applications is limited by list comprehension limitations. Adding the ability to configure termination in the comprehension will increase that number. On Jun 27, 2013, at 7:48 AM, jimjhb@aol.com wrote:
-----Original Message----- From: Joshua Landau <joshua.landau.ws@gmail.com> To: jimjhb <jimjhb@aol.com> Cc: Andrew Barnert <abarnert@yahoo.com>; python-ideas <python-ideas@python.org> Sent: Thu, Jun 27, 2013 9:35 am Subject: Re: [Python-ideas] PEP 315: do-while
On 27 June 2013 14:26, <jimjhb@aol.com> wrote:
Andrew,
I'm not doubting what you are saying, but I am informing the python community of the reality out there. Say what you will, but Python's lack of gotos (if they are bad, then one can just avoid them, right?) is a form of social engineering on Python's part as well. I think that's a good decision, but one can see how social engineering of programmers can go awry as well. (MISRA-C 2012 now allows for limited gotos, so times change.)
If I take the viewpoint of the no break/continue folks, they have a point. They can often be avoided, and throwing them in (a lot) is often a sign of sloppy code. Breaks (especially) are very easy to avoid with the C for, because the conditional is explicit and can easily be expanded. So for C, educating folks with these rules don't really have much net effect.
The PROBLEM is that you can't do that with a Python for. So all this rule indoctrination is much more consequential (to the code).
If can argue that adding a conditional SHOULDN'T be necessary, but that might not reflect our current practical reality.
As the rest of us have said, this is irrelevant.
These people you know are not the norm and no-one is going to budge for them. That's it; and no matter how much you reiterate this is not going to convince even those people who like your suggestion (of which I am not one). Please, just let this point rest. =================== Joshua,
You make a good point. I have no idea how prevalent the problem really is, and that's obviously relevant. (I haven't taken any polls, and neither have you.) Bottom line is most other languages allow early termination of for loops without breaking out of them. Python does not.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
I actually meant to say the reason the idea has gotten some legs... :-) By “legs” I meant lively discussion... On Jun 27, 2013, at 12:21 PM, Shane Green <shane@umbrellacode.com> wrote:
Opinions about break statements are really irrelevant, IMHO. The reason this idea hadn’t taken legs isn’t because of concern about abiding by educators’ blanket rules.
List comprehensions are concise, intuitive, and efficient; proper use can improve readability *and* performance significantly.
The number of proper applications is limited by list comprehension limitations. Adding the ability to configure termination in the comprehension will increase that number.
On Jun 27, 2013, at 7:48 AM, jimjhb@aol.com wrote:
-----Original Message----- From: Joshua Landau <joshua.landau.ws@gmail.com> To: jimjhb <jimjhb@aol.com> Cc: Andrew Barnert <abarnert@yahoo.com>; python-ideas <python-ideas@python.org> Sent: Thu, Jun 27, 2013 9:35 am Subject: Re: [Python-ideas] PEP 315: do-while
On 27 June 2013 14:26, <jimjhb@aol.com> wrote:
Andrew,
I'm not doubting what you are saying, but I am informing the python community of the reality out there. Say what you will, but Python's lack of gotos (if they are bad, then one can just avoid them, right?) is a form of social engineering on Python's part as well. I think that's a good decision, but one can see how social engineering of programmers can go awry as well. (MISRA-C 2012 now allows for limited gotos, so times change.)
If I take the viewpoint of the no break/continue folks, they have a point. They can often be avoided, and throwing them in (a lot) is often a sign of sloppy code. Breaks (especially) are very easy to avoid with the C for, because the conditional is explicit and can easily be expanded. So for C, educating folks with these rules don't really have much net effect.
The PROBLEM is that you can't do that with a Python for. So all this rule indoctrination is much more consequential (to the code).
If can argue that adding a conditional SHOULDN'T be necessary, but that might not reflect our current practical reality.
As the rest of us have said, this is irrelevant.
These people you know are not the norm and no-one is going to budge for them. That's it; and no matter how much you reiterate this is not going to convince even those people who like your suggestion (of which I am not one). Please, just let this point rest. =================== Joshua,
You make a good point. I have no idea how prevalent the problem really is, and that's obviously relevant. (I haven't taken any polls, and neither have you.) Bottom line is most other languages allow early termination of for loops without breaking out of them. Python does not.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
Shane Green writes:
List comprehensions are concise, intuitive, and efficient; proper use can improve readability *and* performance significantly.
Truth, the whole truth, and nothing but the truth.
The number of proper applications is limited by list comprehension limitations.
Truth, but not the whole truth.
Adding the ability to configure termination in the comprehension will increase that number.
Not necessarily. In fact, any programming construct is limited by *human* comprehension limitations. As has been pointed out by people who think about these issues deeply and push these constructs to their limits, *because* a comprehension[1] is an *expression*, nested comprehensions (nested in higher-level expressions) are possible. Adding clauses to the construct increases the complexity, and comprehensions are already pretty complex.[2] Personally, *because* iterables can be infinite, I think the lack of a stop clause in comprehensions is ugly and adds some unobvious complexity to comprehensions and displays. The programmer needs to also keep in mind the possibility that some iterables are infinite, and deal with that. The convenience value of an internal "takewhile()" is also undeniable. I'd like to see the feature added. But I definitely see this as a tradeoff, and I don't know how costly the increased complexity of comprehensions would be to folks who push the limits of comprehension usage already. Increased complexity in the basic construct might push them over the limit, and they would *decrease* usage.[3] Nick et al clearly are concerned about that end of the spectrum, and I personally would place those needs over mine in this case. (YMMV, that's just my opinion about *me*.) Footnotes: [1] Here and below "comprehension" includes generators and displays that take arbitrary iterables. [2] As an objectively verifiable measure (probably pretty imperfect, but relatively objective) of that complexity, at present a fully elaborated comprehension looks like [ # we have a comprehension function(x) # we need to know what function does for x # loop variable we need to track in iterable # we need to know what iterable generates if # optional so need to track "dangling if" condition(x) # we need to know what satisfies condition ] So a comprehension necessarily requires a minimum of 5 facts (each comment describes a fact), sometimes 6, and context (iterable = nested comprehension, etc) will usually add more. So most comprehensions are already at the median of the "7 plus/minus 2" facts that psychologists say that typical humans can operate on simultaneously. Adding another optional clause puts it close to the upper bound of 9, even before considering context and nested comprehensions. [3] True, if such a person is designing from scratch, they can simply make a rule of thumb to avoid the new takewhile feature when they're going to have complex nested comprehensions. But if they're maintaining existing code that already uses the feature, that rule of thumb might cause them to eschew the more extensive changes required to convert to a concise expression in terms of nested comprehensions, or similar.
Stephen Turnbull writes:
Shane Green writes:
List comprehensions are concise, intuitive, and efficient; proper use can improve readability *and* performance significantly.
Truth, the whole truth, and nothing but the truth.
The number of proper applications is limited by list comprehension limitations.
Truth, but not the whole truth.
Adding the ability to configure termination in the comprehension will increase that number.
Not necessarily. In fact, any programming construct is limited by *human* comprehension limitations. As has been pointed out by people who think about these issues deeply and push these constructs to their limits, *because* a comprehension[1] is an *expression*, nested comprehensions (nested in higher-level expressions) are possible. Adding clauses to the construct increases the complexity, and comprehensions are already pretty complex.[2]
Personally, *because* iterables can be infinite, I think the lack of a stop clause in comprehensions is ugly and adds some unobvious complexity to comprehensions and displays. The programmer needs to also keep in mind the possibility that some iterables are infinite, and deal with that. The convenience value of an internal "takewhile()" is also undeniable. I'd like to see the feature added.
But I definitely see this as a tradeoff, and I don't know how costly the increased complexity of comprehensions would be to folks who push the limits of comprehension usage already. Increased complexity in the basic construct might push them over the limit, and they would *decrease* usage.[3] Nick et al clearly are concerned about that end of the spectrum, and I personally would place those needs over mine in this case. (YMMV, that's just my opinion about *me*.)
Footnotes: <deleted> The takewhile syntax is kind of god awful. The lambda thing always gives me pause, though I now 'grok' the whole thing to be a conditional. I don't think the issue is about added complexity to the comprehension (as the added clause would be optional anyway) but the twists and turns needed internally to get it working, and the open question about whether the syntactical implications can be adequately 'contained'.
On 29 June 2013 00:22, <jimjhb@aol.com> wrote:
The takewhile syntax is kind of god awful. The lambda thing always gives me pause, though I now 'grok' the whole thing to be a conditional. I don't think the issue is about added complexity to the comprehension (as the added clause would be optional anyway)
Note that this is a misunderstanding of what "added complexity" means in a language design context. More options almost always mean more complexity. The only way adding more options can simplify things in a practical sense is when they shift complexity from user code to the interpreter implementation by extracting an existing common pattern and giving it dedicated syntax (such as comprehensions, generator expressions and "with" statements), or when they provide a corrected alternative to an existing tempting-but-wrong construct (such as "a if p else b" replacing the "p and a or b" hack and "yield from itr" replacing the coroutine incompatible "for x in itr: yield x"). In this case, the proposal is only tinkering at the edges - you can *always* handle it by creating a custom generator instead. All this proposal does is subtly adjust the point at which it becomes more attractive to write a custom generator function than it is to do the operation in line in the comprehension or generator expression. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Jun 28, 2013 at 2:29 AM, Stephen J. Turnbull <stephen@xemacs.org>wrote:
So most comprehensions are already at the median of the "7 plus/minus 2" facts that psychologists say that typical humans can operate on simultaneously. Adding another optional clause puts it close to the upper bound of 9, even before considering context and nested comprehensions.
That's bogus. One doesn't have to apply all of the "facts" at the same time. More likely one will apply one to three, and refactor if more seem to be needed. One can write "obfuscated Python" with Python as it is today, and that doesn't mean the language should be cut down to "training wheels" state. Cheers, -- Juancarlo *Añez*
27.06.13 02:17, Andrew Barnert написав(ла):
In case it's not obvious how ridiculous it is to extrapolate MISRA-C to other languages…
I went through the 127 rules in MISRA-C 1998. About 52 of them could be extrapolated to Python. Of those, 20 make some sense; the other 32 would be either ridiculous or disastrous to apply in Python. (In fact, much the same is true even for more closely-related languages like C++ or JavaScript.)
If you're curious about the details, see http://stupidpythonideas.blogspot.com/2013/06/misra-c-and-python.html.
Thank you. It's amusing post and interesting blog.
participants (12)
-
Andrew Barnert -
Ethan Furman -
Greg Ewing -
Guido van Rossum -
jimjhb＠aol.com -
Joshua Landau -
Juancarlo Añez -
Nick Coghlan -
Serhiy Storchaka -
Shane Green -
Stephen J. Turnbull -
Łukasz Langa