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-ideas
wrote:
> 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 although we know that the resource has been closed, at
> an 'application' level it is still neccessary
> to deal with the exception - an example might be :
>
> >
> > try:
> > with open('config.cfg', 'r') as cfg:
> > # Process the open file
> > config = load_config(cfg)
> > except FileNotFound:
> > logging.info('Config file not found - using default
> > configuration')
> > except PermissionError:
> > logging.warning('Cannot open config .cfg - using default
> > configuration')
> > config = default_config()
> > else:
> > logging.info('Using config from config.cfg')
> >
> It struck me that this is probably quite a common idiom, and we have
> the main processing (of the opened resources) indented twice just to
> accommodate
> the outer try block.
> 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 with a try - for example the
> above would now look like:
>
> >
> > with open('config.cfg', 'r') as cfg:
> > # Process the open file
> > config = load_config(cfg)
> > except FileNotFound:
> > logging.info('Config file not found - using default
> > configuration')
> > except PermissionError:
> > logging.warning('Cannot open config .cfg - using default
> > configuration')
> > config = default_config()
> > else:
> > logging.info('Using config from config.cfg')
> >
> 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 association of the exception
> from the `with` block is syntactically clear.
> I am not good enough with core development to put together a working
> prototype, but I can imagine that this simple extension would be
> worth while, but I would be more than happy to author a PEP for this
> if it gets some initial positive feedback.
> Open questions - that I have - should we allow `except`, `else` and
> `finally` clauses (or just `except` and `else` - do we need `finally`
> here).
> --
> Anthony Flury
> Moble: +44 07743 282707
> Home: +44 (0)1206 391294
> email: anthony.fl...@btinternet.com
> _______________________________________________
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/ITNCZD2GOQS7TQF7XYFWFYABDP5ZNS5G/
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BG3RT7F7FKCBURC45HCBQXPZL4FPOAOD/
Code of Conduct: http://python.org/psf/codeofconduct/
