[Python-ideas] Control Flow - Never Executed Loop Body

[Michel Desmoulin]

Le 23/03/2016 18:22, Andrew Barnert a écrit :
> On Mar 23, 2016, at 09:48, Michel Desmoulin <desmoulinmichel at gmail.com> wrote:
>>
>> Le 23/03/2016 16:53, Andrew Barnert a écrit :
>>> On Mar 23, 2016, at 03:08, Michel Desmoulin <desmoulinmichel at gmail.com> wrote:
>>>
>>>>> But I think it is a coherent proposal, even if it's not one I like. :)
>>>>
>>>> And what do you think about adding except clauses to if ? with ? while ?
>>>
>>> Well, they don't have the problem that for has (for is already implicitly handling a specific exception in a specific way; none of them are), so they're coherent even without a solution to that problem.
>>>
>>> (With has the additional problem that it may not be immediately obvious on first glance whether the exit gets calls before or after the except clause, but if so, people can read the docs the first time they come across it and remember it after that.)
>>>
>>> But I also think they're even less necessary. They'd all be pure syntactic sugar for nesting the statement and a try/except, so we'd be making the language more complicated to learn and remember, and encouraging more code that isn't backward compatible. That's not a huge cost, but the benefit isn't very big either. For _really_ short cases, I think we want except expressions (PEP 463); for longish code, there's nothing wrong with an explicit try; the range for which hiding an implicit try inside if and while would really improve things is small enough that I don't think the benefit outweighs the cost.
>>
>> Would love to see except expression win, but hasn't been rejected by the
>> BDFL ? Plus it's not really related to the current proposal.
> 
> I thought PEP 463 was just stalled waiting on a reference implementation before he'd declare either way?
> 
> At any rate, the reason it's related is that every case I could think of where I'd want to use if/except is so trivial that I'd much rather use an if expression in an except expression. There may be cases that are not quite trivial enough to demand that, but still small enough that saving one line of code makes a difference; just because I can't think of any certainly doesn't mean they don't exist. :)
> 
> But, given the rest of your reply, I guess it doesn't matter.
> 
>>> But maybe some good examples of realistic 3-liners that are significantly improved by the change would convince me (and, more importantly, convince a majority of the others who are skeptical), so I'll keep an open mind.
>>
>> The more I think about it, the more I think it's bad idea. We are mixing
>> semantics of loops and exceptions or conditions and exceptions.
>>
>> I withdraw this part of the "general exceptions" proposal. I'm going
>> back to the simpler and less dangerous proposal:
>>
>> for stuff in foo:
>>   bar(stuff)
>> or:
>>   default()
> 
> You may want to get everyone back on track by writing a complete proposal (does or come before or after else? what exactly are the semantics? how does it translate to bytecode, if you understand how for already translates?) with just this suggestion some motivating examples.
> 
> I still think this isn't really necessary. In every case I can think of where I really want to do something special on empty, I definitely have a sequence, and can just do "if not foo:", or I need a count rather than just an empty flag, or I'm already doing some EAFP handling, or... But again, just because I can't think of examples doesn't mean they don't exist. It just implies that maybe the other people you're trying to convince can't think of them either, so it would be better for you to show us.
> 

Ok, but before that, is anyone still attached to another solution ?