My application-level
> exception handling is rarely that close to the file operations,
> it's usually at a much higher level.
With is used for lots of other things, too. Does this same point apply to
other use cases?
For my part, I still find the extra indentation annoying required for with
to
On Fri, Apr 9, 2021 at 8:22 AM Ethan Furman wrote:
>
> On 4/8/21 2:40 PM, Chris Angelico wrote:
>
> > At least in this form, it's clear that there's a sharp distinction
> > between the stuff around the outside of the 'with' block and the stuff
> > inside it.
> >
> > The semantics, as suggested, gi
On 9/04/21 2:59 am, anthony.flury via Python-ideas wrote:
I was wondering whether a worthwhile extension might be to allow the
`with` statement to have an `except` and `else` clauses
I don't think I would find this very useful. My application-level
exception handling is rarely that close to the
On 4/8/21 2:40 PM, Chris Angelico wrote:
At least in this form, it's clear that there's a sharp distinction
between the stuff around the outside of the 'with' block and the stuff
inside it.
The semantics, as suggested, give 'with' blocks two distinct
exception-management scopes, which mostly bu
On Fri, Apr 9, 2021 at 6:41 AM Ethan Furman wrote:
>
> On 4/8/21 1:21 PM, Chris Angelico wrote:
> > On Fri, Apr 9, 2021 at 6:16 AM Ethan Furman wrote:
> >> On 4/8/21 11:25 AM, Chris Angelico wrote:
>
> >>> Similar question: What would be the semantics of this?
> >>>
> >>> with contextlib.suppress(
Hello,
I would like to propose adding literal syntax to allow creation of an empty set
without the need to call the type constructor. I believe the best choice for
such a literal, and one that has been proposed before, is `{,}`.
I know this idea has surfaced a few times before, but I cannot fin
On 4/8/21 1:21 PM, Chris Angelico wrote:
On Fri, Apr 9, 2021 at 6:16 AM Ethan Furman wrote:
On 4/8/21 11:25 AM, Chris Angelico wrote:
Similar question: What would be the semantics of this?
with contextlib.suppress(BaseException):
a = b / c
except BaseException as e:
print(e)
Wha
On Fri, Apr 9, 2021 at 6:16 AM Ethan Furman wrote:
>
> On 4/8/21 11:25 AM, Chris Angelico wrote:
>
> > Similar question: What would be the semantics of this?
> >
> > with contextlib.suppress(BaseException):
> > a = b / c
> > except BaseException as e:
> > print(e)
> >
> > What types of e
On 4/8/21 11:25 AM, Chris Angelico wrote:
Similar question: What would be the semantics of this?
with contextlib.suppress(BaseException):
a = b / c
except BaseException as e:
print(e)
What types of exception could be caught and what types couldn't?
Well, if every exception is deriv
On Fri, Apr 9, 2021 at 1:38 AM anthony.flury via Python-ideas
wrote:
> ... indented twice just to accommodate the outer try block.
>
> Treating the 'with' as an implied `try` would reduce the march to the right -
> now the key processing of the resource is now indented only one level - and
> the
I think I like it.
Q. Safe to assume this would catch exceptions from both the call to
`open` as well as the call to `open.__enter__`?
Q. What about something even more verbose (descriptive) like`try with
open(...) as cfg:`? 🙂
Paul
On Thu, 2021-04-08 at 15:59 +0100, anthony.flury via Python-i
On Thu, Apr 8, 2021, 11:39 AM anthony.flury via Python-ideas <
python-ideas@python.org> wrote:
> I was wondering whether a worthwhile extension might be to allow the
> `with` statement to have an `except` and `else` clauses which would have
> the same
>
> semantics as wrapping the `with` block wi
We are all familiar with the `with` statement for context managers, so
that the resources are correctly finalized/closed in case of an
exception either in terms
of the resources being allocated of the processing.
It is very common though to wrap the `with block` in an outer `try`
block, since
13 matches
Mail list logo
