On Wed, Nov 8, 2017 at 11:34 AM, Chris Angelico wrote:
> On Thu, Nov 9, 2017 at 5:20 AM, Ian Kelly wrote:
>> On Wed, Nov 8, 2017 at 11:12 AM, Chris Angelico wrote:
>>> Except that "yield from" is used by generators to delegate to other
>>> generators, and "await" is used by coroutines to delegat
On Thu, Nov 9, 2017 at 5:20 AM, Ian Kelly wrote:
> On Wed, Nov 8, 2017 at 11:12 AM, Chris Angelico wrote:
>> Except that "yield from" is used by generators to delegate to other
>> generators, and "await" is used by coroutines to delegate to other
>> coroutines. In an asynchronous generator, "yiel
On Wed, Nov 8, 2017 at 11:12 AM, Chris Angelico wrote:
> On Thu, Nov 9, 2017 at 5:05 AM, Ian Kelly wrote:
>> On Wed, Nov 8, 2017 at 9:31 AM, Chris Angelico wrote:
>>> On Thu, Nov 9, 2017 at 3:19 AM, Ian Kelly wrote:
I was not referring to the possible future use of yield from for async
>>>
On Thu, Nov 9, 2017 at 5:05 AM, Ian Kelly wrote:
> On Wed, Nov 8, 2017 at 9:31 AM, Chris Angelico wrote:
>> On Thu, Nov 9, 2017 at 3:19 AM, Ian Kelly wrote:
>>> I was not referring to the possible future use of yield from for async
>>> generators; I was referring to the possibility *today* of us
On Wed, Nov 8, 2017 at 9:31 AM, Chris Angelico wrote:
> On Thu, Nov 9, 2017 at 3:19 AM, Ian Kelly wrote:
>> I was not referring to the possible future use of yield from for async
>> generators; I was referring to the possibility *today* of using "yield
>> from" as a synonym for *await*. As far as
On Thu, Nov 9, 2017 at 3:19 AM, Ian Kelly wrote:
> I was not referring to the possible future use of yield from for async
> generators; I was referring to the possibility *today* of using "yield
> from" as a synonym for *await*. As far as I know the only major
> obstacle to that is that the author
On Tue, Nov 7, 2017 at 2:42 PM, Chris Angelico wrote:
> On Wed, Nov 8, 2017 at 8:16 AM, Ian Kelly wrote:
>>> Not one of these is syntactically invalid. Why should "else without
>>> break" be trapped by the parser? Your other examples mostly have good
>>> parser-level reasons for being errors
>>
>
On Tue, Nov 7, 2017 at 4:28 PM, Steve D'Aprano
wrote:
> On Wed, 8 Nov 2017 04:28 am, Ian Kelly wrote:
>
>> Steve's manufactured interactive example ("manufactured" because
>> who really uses for-else interactively? If I really care that much
>> about output formatting I'm going to put it in a scr
On Wed, 8 Nov 2017 04:28 am, Ian Kelly wrote:
> Steve's manufactured interactive example ("manufactured" because
> who really uses for-else interactively? If I really care that much
> about output formatting I'm going to put it in a script).
Me. As I have said.
I really don't appreciate you imp
On Wed, Nov 8, 2017 at 8:16 AM, Ian Kelly wrote:
> All of these are things that a linter should probably catch and warn
> about. If you had said that the break syntax suggestion was a good
> idea but probably better suited as a linter warning than as a
> SyntaxError integrated into the parser, the
On Tue, Nov 7, 2017 at 12:10 PM, Chris Angelico wrote:
> On Wed, Nov 8, 2017 at 4:28 AM, Ian Kelly wrote:
>> On Sat, Nov 4, 2017 at 6:40 AM, Chris Angelico wrote:
>>> Maybe we're not defending the abuse of other contributors. Maybe we're
>>> defending a legitimate, if somewhat caustic, response
On Wed, Nov 8, 2017 at 4:28 AM, Ian Kelly wrote:
> On Sat, Nov 4, 2017 at 6:40 AM, Chris Angelico wrote:
>> On Sat, Nov 4, 2017 at 11:25 PM, Jon Ribbens
>> wrote:
>>> On 2017-11-04, Ben Finney wrote:
To respond to the criticism of an idea – criticism containing no mention
of the pers
On Sat, Nov 4, 2017 at 6:40 AM, Chris Angelico wrote:
> On Sat, Nov 4, 2017 at 11:25 PM, Jon Ribbens
> wrote:
>> On 2017-11-04, Ben Finney wrote:
>>> To respond to the criticism of an idea – criticism containing no mention
>>> of the person – as though it “clearly refers to the [person]”, is of
On Fri, Nov 3, 2017 at 11:55 PM, Ben Finney wrote:
> Ian Kelly writes:
>
>> Please stop defending the use of incivility on this list.
>
> Please stop conflating people, who deserve civility, with ideas. We must
> not allow the civility deserved by people, to prevent us from
> criticising any idea
I haven't read over every message in the thread, so sorry if this has
been suggested before, but how about "if not break:" and "if not
except:" as synonyms for the current 'else' clause? They're already
keywords, and this sequence of keywords has no current meaning.
--
https://mail.python.org/mail
Just a little two-cent opinion from the peanut gallery:
I've been following all the discussion on this go by, sometimes getting
a bit heated at times, and just sitting nice and safe and secure in my
little ivory tower, where I simply tell my students to not use 'break'.
As a stodgy educator,
On 11/6/17 8:05 AM, Jon Ribbens wrote:
On 2017-11-06, Chris Angelico wrote:
If you start with the assumption that "intuitively obvious" doesn't
actually mean "intuitively obvious" but actually means something
completely different, then your statement definitely means something
non-contradictory
On Tue, Nov 7, 2017 at 12:05 AM, Jon Ribbens wrote:
> On 2017-11-06, Chris Angelico wrote:
>> If you start with the assumption that "intuitively obvious" doesn't
>> actually mean "intuitively obvious" but actually means something
>> completely different, then your statement definitely means somet
On 2017-11-06, Chris Angelico wrote:
> If you start with the assumption that "intuitively obvious" doesn't
> actually mean "intuitively obvious" but actually means something
> completely different, then your statement definitely means something
> non-contradictory. But if you start with the assump
On Mon, Nov 6, 2017 at 10:34 PM, Jon Ribbens wrote:
> On 2017-11-06, Ben Finney wrote:
>> Jon Ribbens writes:
>>> On 2017-11-05, Ben Finney wrote:
>>> > Jon Ribbens writes:
>>> >> I've provided you with a way of thinking about 'for...else' that makes
>>> >> its purpose and meaning intuitively
On 06/11/2017 02:28, Steve D'Aprano wrote:
On Sat, 4 Nov 2017 03:57 pm, Michael Torrie wrote:
Can you be more specific? What are some of these "many" ways of aborting
a loop? Help a guy out here.
Aside from more exotic methods such as os.abort, os._exit and signal handlers,
the common ways
On 2017-11-06, Ben Finney wrote:
> Jon Ribbens writes:
>> On 2017-11-05, Ben Finney wrote:
>> > Jon Ribbens writes:
>> >> I've provided you with a way of thinking about 'for...else' that makes
>> >> its purpose and meaning intuitively obvious.
>> >
>> > I've read that sentence several times, an
On Sat, 4 Nov 2017 03:57 pm, Michael Torrie wrote:
> On 11/03/2017 09:06 PM, Chris Angelico wrote:
>> On Sat, Nov 4, 2017 at 1:57 PM, Michael Torrie wrote:
>>> On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
> In fact if you have no b
On Mon, 6 Nov 2017 01:39 am, Jon Ribbens wrote:
> On 2017-11-05, Steve D'Aprano wrote:
>> On Sat, 4 Nov 2017 04:44 am, Jon Ribbens wrote:
>>> That conforms to my model. It's searching for the condition
>>> 'count > MAX_OBJECTS'.
>>
>> That's sounds to me that you are willing to call just about an
On Mon, Nov 6, 2017 at 11:06 AM, Steve D'Aprano
wrote:
> On Mon, 6 Nov 2017 10:06 am, Jon Ribbens wrote:
>
>> On 2017-11-05, Ben Finney wrote:
>>> Jon Ribbens writes:
I've provided you with a way of thinking about 'for...else' that makes
its purpose and meaning intuitively obvious.
>>>
On Mon, 6 Nov 2017 10:06 am, Jon Ribbens wrote:
> On 2017-11-05, Ben Finney wrote:
>> Jon Ribbens writes:
>>> I've provided you with a way of thinking about 'for...else' that makes
>>> its purpose and meaning intuitively obvious.
>>
>> I've read that sentence several times, and I still can't mak
Jon Ribbens writes:
> On 2017-11-05, Ben Finney wrote:
> > Jon Ribbens writes:
> >> I've provided you with a way of thinking about 'for...else' that makes
> >> its purpose and meaning intuitively obvious.
> >
> > I've read that sentence several times, and I still can't make it
> > anything but
On 2017-11-05, Ben Finney wrote:
> Jon Ribbens writes:
>> I've provided you with a way of thinking about 'for...else' that makes
>> its purpose and meaning intuitively obvious.
>
> I've read that sentence several times, and I still can't make it
> anything but a contradiction in terms.
Well, kee
Jon Ribbens writes:
> I've provided you with a way of thinking about 'for...else' that makes
> its purpose and meaning intuitively obvious.
I've read that sentence several times, and I still can't make it
anything but a contradiction in terms.
Something that is “intuitively obvious” surely has
On 2017-11-05, Steve D'Aprano wrote:
> On Sat, 4 Nov 2017 04:44 am, Jon Ribbens wrote:
>> That conforms to my model. It's searching for the condition
>> 'count > MAX_OBJECTS'.
>
> That's sounds to me that you are willing to call just about any test of a
> condition inside a loop a "search". I don'
On Sat, 4 Nov 2017 04:44 am, Jon Ribbens wrote:
> On 2017-11-03, Steve D'Aprano wrote:
>> The for loop does not necessarily perform a search:
>>
>> count = 1
>> for obj in sequence:
>> if count > MAX_OBJECTS:
>> print("too many objects, halting")
>> break
>> process(obj)
>
On Sat, Nov 4, 2017 at 11:22 PM, Jon Ribbens wrote:
> On 2017-11-04, Michael Torrie wrote:
>> On 11/03/2017 09:06 PM, Chris Angelico wrote:
>>> On Sat, Nov 4, 2017 at 1:57 PM, Michael Torrie wrote:
On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
> That's incorrect. There are multiple ways
On Sat, Nov 4, 2017 at 11:25 PM, Jon Ribbens wrote:
> On 2017-11-04, Ben Finney wrote:
>> To respond to the criticism of an idea – criticism containing no mention
>> of the person – as though it “clearly refers to the [person]”, is of
>> significant concern on a software dicussion forum such as t
On 2017-11-04, Ben Finney wrote:
> To respond to the criticism of an idea – criticism containing no mention
> of the person – as though it “clearly refers to the [person]”, is of
> significant concern on a software dicussion forum such as this.
No, the thing that is "of significant conern on a so
On 2017-11-04, Michael Torrie wrote:
> On 11/03/2017 09:06 PM, Chris Angelico wrote:
>> On Sat, Nov 4, 2017 at 1:57 PM, Michael Torrie wrote:
>>> On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
That's incorrect. There are multiple ways to exit a loop that
will prevent the `else` block fro
Ian Kelly writes:
> Steve was clearly referring to the coder, not the code.
Not at all. Steve was referring specifically to the *idea*:
[A ‘for … else’ structure without a ‘break’] should absolutely not
be a syntax error. There's no reason for it to be a syntax error,
except to sati
On 11/03/2017 09:06 PM, Chris Angelico wrote:
> On Sat, Nov 4, 2017 at 1:57 PM, Michael Torrie wrote:
>> On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
>>> On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
>>>
In fact if you have no break you may as well drop the
else entirely, because t
On Sat, Nov 4, 2017 at 1:57 PM, Michael Torrie wrote:
> On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
>> On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
>>
>>> In fact if you have no break you may as well drop the
>>> else entirely, because the block will always execute.
>>
>> That's incorrect.
On 11/03/2017 07:09 PM, Steve D'Aprano wrote:
> On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
>
>> In fact if you have no break you may as well drop the
>> else entirely, because the block will always execute.
>
> That's incorrect. There are multiple ways to exit a loop that will prevent the
On Sat, 4 Nov 2017 06:15 am, Michael Torrie wrote:
> In fact if you have no break you may as well drop the
> else entirely, because the block will always execute.
That's incorrect. There are multiple ways to exit a loop that will prevent the
`else` block from executing, `break` is only one.
--
On Fri, Nov 3, 2017 at 3:25 PM, Stefan Ram wrote:
> Jon Ribbens writes:
>>No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>Like I said, that should probably be a syntax error.
>
> It should make the syntax of Python much more complicated,
> when one would try to encode this
On 11/03/2017 11:44 AM, Jon Ribbens wrote:
> And that's leading you into confusion, as you've demonstrated.
And indeed I've been led into considerable confusion about the else:
clause over the years. Every time I need to use it, I run a python shell
and try it out to remind myself how it works. H
On Fri, Nov 3, 2017 at 8:32 AM, Chris Angelico wrote:
> On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens
> wrote:
>> On 2017-11-03, Steve D'Aprano wrote:
>>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
No, it's an obvious bug. You have a 'for...else' with no 'break'.
Like I said, that
On 2017-11-03, Steve D'Aprano wrote:
> The for loop does not necessarily perform a search:
>
> count = 1
> for obj in sequence:
> if count > MAX_OBJECTS:
> print("too many objects, halting")
> break
> process(obj)
> else:
> print("finished")
>
> According to your mental
On 2017-11-03, Chris Angelico wrote:
> On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens
> wrote:
>>> It should absolutely not be a syntax error. There's no reason for it
>>> to be a syntax error, except to satisfy some arrogant and foolish
>>> idea of purity.
>>
>> It'd be nice if you could be a lit
On Fri, 3 Nov 2017 10:49 pm, Jon Ribbens wrote:
> On 2017-11-03, Steve D'Aprano wrote:
>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
>>> No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>> Like I said, that should probably be a syntax error.
>>
>> It should absolutely not b
On Sat, Nov 4, 2017 at 3:15 AM, Alexey Muranov wrote:
> On Fri, 2017-11-03 at 22:03 +1100, Chris Angelico wrote:
>> On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov > com> wrote:
>> > 'Then' describes what happens next indeed, unless some
>> > extraordinary
>> > situation prevents it from happening,
On Fri, 2017-11-03 at 22:03 +1100, Chris Angelico wrote:
> On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov com> wrote:
> > 'Then' describes what happens next indeed, unless some
> > extraordinary
> > situation prevents it from happening, for example:
> >
> > try:
> > go_to_the_bakery()
On Fri, Nov 3, 2017 at 10:49 PM, Jon Ribbens wrote:
> On 2017-11-03, Steve D'Aprano wrote:
>> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
>>> No, it's an obvious bug. You have a 'for...else' with no 'break'.
>>> Like I said, that should probably be a syntax error.
>>
>> It should absolutely n
On 03/11/2017 11:49, Jon Ribbens wrote:
On 2017-11-03, Steve D'Aprano wrote:
Right, which is what happens with the for...else block.
No. Ok, so look. It's obvious that you and I have different mental
models of the situation here. You're thinking of 'for...else' as two
arbitrary clauses that
On 2017-11-03, Steve D'Aprano wrote:
> On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
>> No, it's an obvious bug. You have a 'for...else' with no 'break'.
>> Like I said, that should probably be a syntax error.
>
> It should absolutely not be a syntax error. There's no reason for it
> to be a syn
On 2017-11-03, Alexey Muranov wrote:
> 'Then' describes what happens next indeed, unless some extraordinary
> situation prevents it from happening, for example:
>
> try:
> go_to_the_bakery()
> then:
> buy_croissants(2)
> except BakeryClosed:
> go_to_the_grocier
On Fri, Nov 3, 2017 at 8:48 PM, Alexey Muranov wrote:
> 'Then' describes what happens next indeed, unless some extraordinary
> situation prevents it from happening, for example:
>
>try:
>go_to_the_bakery()
>then:
>buy_croissants(2)
>except BakeryClosed:
>go_to_t
On Thu, 2017-11-02 at 16:31 +, Jon Ribbens wrote:
> On 2017-11-02, Steve D'Aprano wrote:
> > On Fri, 3 Nov 2017 12:39 am, Jon Ribbens wrote:
> > > Why would we want to make the language worse? It is fairly
> > > obvious
> > > what 'else' means,
> >
> > Yes, obvious and WRONG.
>
> Nope, o
On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:
> On 2017-11-02, Steve D'Aprano wrote:
>> On Fri, 3 Nov 2017 12:39 am, Jon Ribbens wrote:
>>> Why would we want to make the language worse? It is fairly obvious
>>> what 'else' means,
>>
>> Yes, obvious and WRONG.
>
> Nope, obvious and right.
>
>>
On 11/02/2017 06:09 PM, Skip Montanaro wrote:
Eh, what can I say? I guess I was paying too much attention to the baseball
game. Yes, "else" handles the "fall off the end" termination, not the "exit
early" termination. My apologies. I do think that having a way to spell "do
this when the loop exit
Eh, what can I say? I guess I was paying too much attention to the baseball
game. Yes, "else" handles the "fall off the end" termination, not the "exit
early" termination. My apologies. I do think that having a way to spell "do
this when the loop exits early" makes things clearer. So, perhaps while
On 2017-11-02, Steve D'Aprano wrote:
> On Fri, 3 Nov 2017 12:39 am, Jon Ribbens wrote:
>> Why would we want to make the language worse? It is fairly obvious
>> what 'else' means,
>
> Yes, obvious and WRONG.
Nope, obvious and right.
> for x in seq:
> do_something()
> else:
> print("seq w
On Fri, 3 Nov 2017 12:39 am, Jon Ribbens wrote:
> On 2017-11-01, Alexey Muranov wrote:
>> what do you think about the idea of replacing "`else`" with "`then`" in
>> the contexts of `for` and `try`?
>>
>> It seems clear that it should be rather "then" than "else." Compare
>> also "try ... then ..
On Wednesday, November 1, 2017 at 9:14:05 PM UTC, Alexey Muranov wrote:
> Hello,
>
> what do you think about the idea of replacing "`else`" with "`then`" in
> the contexts of `for` and `try`?
>
> It seems clear that it should be rather "then" than "else." Compare
> also "try ... then ... final
On 2017-11-01, Alexey Muranov wrote:
> what do you think about the idea of replacing "`else`" with "`then`" in
> the contexts of `for` and `try`?
>
> It seems clear that it should be rather "then" than "else." Compare
> also "try ... then ... finally" with "try ... else ... finally".
>
> Curren
On Wed, Nov 1, 2017 at 5:12 PM, Alexey Muranov
wrote:
> what do you think about the idea of replacing "`else`" with "`then`" in
> the contexts of `for` and `try`?
>
I wish the core python developers had done it 20 years ago. Given that
python is a relatively mature language at this point, I d
Steve D'Aprano writes:
> On Thu, 2 Nov 2017 10:09 pm, Ben Bacarisse wrote:
>
>> Sure, but your argument seemed to that else has entirely the wrong
>> meaning (I certainly to a double take when I have to remember what it
>> means) and, in that context, finally has a meaning closer to what you
>> w
On Thu, 2 Nov 2017 10:09 pm, Ben Bacarisse wrote:
> Sure, but your argument seemed to that else has entirely the wrong
> meaning (I certainly to a double take when I have to remember what it
> means) and, in that context, finally has a meaning closer to what you
> want.
That's an argument about w
Steve D'Aprano writes:
> On Thu, 2 Nov 2017 12:50 pm, Ben Bacarisse wrote:
>
>> Steve D'Aprano writes:
>>
>>> On Thu, 2 Nov 2017 08:12 am, Alexey Muranov wrote:
>>>
what do you think about the idea of replacing "`else`" with "`then`" in
the contexts of `for` and `try`?
> [...]
>> Re-u
On Thu, 2 Nov 2017 09:04 pm, Steve D'Aprano wrote:
> then (with special case) of `pass`
That should read "then except for the special case of `pass`".
Sorry.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.o
On Thu, 2 Nov 2017 12:49 pm, Skip Montanaro wrote:
> I don't know. The word "then" doesn't connote different ways of exiting a
> loop to me ("else" doesn't really either, I will grant you that, but it's
> what we have). Here's how I would read things:
>
>- *while* some condition holds, execut
On Thu, Nov 2, 2017 at 7:05 PM, Alexey Muranov wrote:
> On Wed, 2017-11-01 at 21:30 +, Stefan Ram wrote:
>>
>> >
>> > In languages like Algol 68, »then« is used for a clause
>> > that is to be executed when the main condition of an
>> > if-statement /is/ true, so this might cause some co
On Thu, 2017-11-02 at 08:21 +1100, Chris Angelico wrote:
>
>
With try/except/else, it's "do this, and if an exception happens, do
this, else do this". So else makes perfect sense.
Indeed, i forgot about `except`. I agree that
"try/then/except/finally" would be better than
"try/except/then/f
On 11/1/2017 5:12 PM, Alexey Muranov wrote:
what do you think about the idea of replacing "`else`" with "`then`" in
the contexts of `for` and `try`?
This idea has been argued to death more than once before. I am opposed
on both logical and practical grounds, but will not repeat myself for
t
On Wed, 2017-11-01 at 21:30 +, Stefan Ram wrote:
>
> In languages like Algol 68, »then« is used for a clause
> that is to be executed when the main condition of an
> if-statement /is/ true, so this might cause some confusion.
>
sure, and `else` is used for a clause that is to be execu
On Thu, 2017-11-02 at 08:29 +1100, Chris Angelico wrote:
> On Thu, Nov 2, 2017 at 8:23 AM, Ned Batchelder
> > wrote:
> >
> >
> > Apart from the questions of backward compatibility etc (Python is
> > unlikely
> > to ever go through another shift like the 2/3 breakage), are you
> > sure "then"
>
On Thu, Nov 2, 2017 at 12:42 PM, bartc wrote:
> But if people prefer a different keyword, then why not? I think 'then' can
> be used, without impacting its use as an identifier, because it will always
> be followed by ":". Of course you would need to allow both "else" and "then"
> for backwards co
On Thu, 2 Nov 2017 12:50 pm, Ben Bacarisse wrote:
> Steve D'Aprano writes:
>
>> On Thu, 2 Nov 2017 08:12 am, Alexey Muranov wrote:
>>
>>> what do you think about the idea of replacing "`else`" with "`then`" in
>>> the contexts of `for` and `try`?
[...]
> Re-using finally would not need a new key
On Thu, Nov 2, 2017 at 12:19 PM, Steve D'Aprano
wrote:
> On Thu, 2 Nov 2017 08:21 am, Chris Angelico wrote:
>
>> With the 'for' loop,
>> it's a bit more arguable, but I've never seen anything more than a
>> weak argument in favour of 'then'
>
> Thhpptpt!
>
> "else" is an completely inappropriate t
Steve D'Aprano writes:
> On Thu, 2 Nov 2017 08:12 am, Alexey Muranov wrote:
>
>> what do you think about the idea of replacing "`else`" with "`then`" in
>> the contexts of `for` and `try`?
>
> Yes, this, exactly!!!
>
> (For while and for loops, but not try -- see below.)
>
> I have argued this fo
I don't know. The word "then" doesn't connote different ways of exiting a
loop to me ("else" doesn't really either, I will grant you that, but it's
what we have). Here's how I would read things:
- *while* some condition holds, execute the loop, possibly breaking out,
*then* do some finishing
On 02/11/2017 01:06, Steve D'Aprano wrote:
On Thu, 2 Nov 2017 08:12 am, Alexey Muranov wrote:
Hello,
what do you think about the idea of replacing "`else`" with "`then`" in
the contexts of `for` and `try`?
Yes, this, exactly!!!
(For while and for loops, but not try -- see below.)
I have a
On 02/11/2017 01:19, Steve D'Aprano wrote:
On Thu, 2 Nov 2017 08:21 am, Chris Angelico wrote:
With the 'for' loop,
it's a bit more arguable, but I've never seen anything more than a
weak argument in favour of 'then'
Thhpptpt!
"else" is an completely inappropriate term that doesn't describe t
On Thu, 2 Nov 2017 08:23 am, Ned Batchelder wrote:
> Apart from the questions of backward compatibility etc (Python is
> unlikely to ever go through another shift like the 2/3 breakage), are
> you sure "then" is what you mean? This won't print "end":
>
> for i in range(10):
> print(i)
> e
On Thu, 2 Nov 2017 08:21 am, Chris Angelico wrote:
> With the 'for' loop,
> it's a bit more arguable, but I've never seen anything more than a
> weak argument in favour of 'then'
Thhpptpt!
"else" is an completely inappropriate term that doesn't describe the semantics
of the statement even a litt
On Thu, 2 Nov 2017 08:12 am, Alexey Muranov wrote:
> Hello,
>
> what do you think about the idea of replacing "`else`" with "`then`" in
> the contexts of `for` and `try`?
Yes, this, exactly!!!
(For while and for loops, but not try -- see below.)
I have argued this for many years. The current
On 11/1/17 5:29 PM, Chris Angelico wrote:
On Thu, Nov 2, 2017 at 8:23 AM, Ned Batchelder wrote:
On 11/1/17 5:12 PM, Alexey Muranov wrote:
Hello,
what do you think about the idea of replacing "`else`" with "`then`" in
the contexts of `for` and `try`?
It seems clear that it should be rather "t
On Thu, Nov 2, 2017 at 8:23 AM, Ned Batchelder wrote:
> On 11/1/17 5:12 PM, Alexey Muranov wrote:
>>
>> Hello,
>>
>> what do you think about the idea of replacing "`else`" with "`then`" in
>> the contexts of `for` and `try`?
>>
>> It seems clear that it should be rather "then" than "else." Compare
On 11/1/17 5:12 PM, Alexey Muranov wrote:
Hello,
what do you think about the idea of replacing "`else`" with "`then`"
in the contexts of `for` and `try`?
It seems clear that it should be rather "then" than "else." Compare
also "try ... then ... finally" with "try ... else ... finally".
Cur
On Thu, Nov 2, 2017 at 8:12 AM, Alexey Muranov wrote:
> Hello,
>
> what do you think about the idea of replacing "`else`" with "`then`" in the
> contexts of `for` and `try`?
>
> It seems clear that it should be rather "then" than "else." Compare also
> "try ... then ... finally" with "try ... els
Hello,
what do you think about the idea of replacing "`else`" with "`then`" in
the contexts of `for` and `try`?
It seems clear that it should be rather "then" than "else." Compare
also "try ... then ... finally" with "try ... else ... finally".
Currently, with "else", it is almost impossib
87 matches
Mail list logo
