2023-08-01 21:46 UTC+02:00, Ronald Oussoren via Python-ideas
:
>
>
>> On 1 Aug 2023, at 19:59, Mitch wrote:
>>
>> Is this a relevant argument (either way) here?
>
> Adding features to the language always has a cost in that it slightly
> complicates the language and makes it harder to teach. Becaus
On Tue, 8 Aug 2023 at 00:09, Celelibi wrote:
> Actually, now that I think about it, I guess a 'try' block without an
> 'except' and just a 'finally' would probably be a good candidate for a
> context manager. (Which I'm a big fan of. ^^)
Yeah, context managers are often a good way of writing a tr
2023-08-01 18:14 UTC+02:00, Chris Angelico :
> On Wed, 2 Aug 2023 at 02:02, Celelibi wrote:
>> If later on an "except" is added, the developper doing the
>> modification should be reminded to move the call to
>> no_error_occurred() into an "else". With real-world non-trivial code,
>> it might not
Yeah, my mental model got the better of me there. I conceptualize
try/except as deferring subsequent reraises in the try block, so in that
case the "catch all --> do nothing ( --> defer reraise)" and "catch nothing
(--> defer reraise)" cases were equivalent. But the way I wrote it was
confusing bec
On Wed, 2 Aug 2023 at 08:22, Mitch wrote:
>
> If `except` is omitted, then catch the generic exception and do nothing and
> exit.
>
Not sure what you mean here. If you have a try-finally with no except
clause, no exceptions will be caught; the try will be run, then the
finally, and then you'll s
Hmm, ok, I can work with that :)
If I were writing Python right now, I would argue that if you're going to
build this try/except/else/finally construct, each of the three result
clauses represent potential outcomes. The fail case, the success case, and
the no-matter-what case. And then, you should
On Wed, 2 Aug 2023 at 04:03, Mitch wrote:
> I'll ask the same question as OP: "Is there a reason why else without except
> has to be invalid syntax?"
>
A better question is: "Is there a reason why else without except
should be valid syntax?"
ChrisA
__
> On 1 Aug 2023, at 19:59, Mitch wrote:
>
> Is this a relevant argument (either way) here?
Adding features to the language always has a cost in that it slightly
complicates the language and makes it harder to teach. Because of that the bar
for adding features is high.
Showing how a new fea
Reading on mobile I missed that you were referencing Celelibi's answer and
not the thread generally [facepalm]. My apologies for that.
I've been previously bitten (multiple times) by code where a developer has
used a try/except to catch errors from one of several actions in a try
block, but a bug
Is this a relevant argument (either way) here?
While I appreciate considering the applicability of the argument to
existing code is generally a good thing, I'm not sure that it makes sense
for cases like this where a logical outcome seems to be missing. If you can
try/finally and then implicitly p
On Wed, 2 Aug 2023 at 02:02, Celelibi wrote:
> If later on an "except" is added, the developper doing the
> modification should be reminded to move the call to
> no_error_occurred() into an "else". With real-world non-trivial code,
> it might not be so simple to see.
>
Can you give us an example
2023-06-30 19:54 UTC+02:00, MRAB :
> On 2023-06-30 14:55, Daniel Walker wrote:
>> As most of you probably know, you can use else with try blocks:
>>
>> try:
>> do_stuff()
>> except SomeExceptionClass:
>> handle_error()
>> else:
>> no_error_occurred()
>>
>> Here, no_error_occurred will
On 2023-06-30 14:55, Daniel Walker wrote:
As most of you probably know, you can use else with try blocks:
try:
do_stuff()
except SomeExceptionClass:
handle_error()
else:
no_error_occurred()
Here, no_error_occurred will only be called if do_stuff() didn't raise
an exception.
Howe
13 matches
Mail list logo
