[Python-Dev] Re: Reviving PEP 473
For best performance (reduce time to build an exception object), I
would be interested to only format the error message on demand. For
example, when str(exception) is called.
The problem is the Exception.args attribute. Example:
$ ./python
Python 3.10.0a6+
>>> exc=AttributeError("%s object has no attribute %s" % ("MyObject", "name"))
>>> str(exc)
'MyObject object has no attribute name'
>>> exc.args
('MyObject object has no attribute name',)
Currently, args is the raw positional arguments passed to the
Exception constructor, and they are very likely many applications
relying on Exception.args.
For backward compatibility, we could store "%s object has no attribute
%s" and ("MyObject", "name"), and build the args tuple on demand and
format the string at the first str() call.
At the C level, args is exposed directly as PyBaseExceptionObject.args
and the PyBaseExceptionObject structure is part of the public C API.
Changing it would be a C API incompatible change.
By the way, the PEP 473 doesn't say anything about it and has no
"Backward compatibility" section :-(
Victor
On Sat, Mar 13, 2021 at 7:49 PM Sebastian Kreft wrote:
>
> Hi dev-team, I'm reopening the discussion of PEP 473, which was closed due to:
>
> The steering council felt the PEP was too broad and not focused enough.
> Discussions about adding more attributes to built-in exceptions can continue
> on the issue tracker on a per-exception basis (and obviously here for any
> broader points, e.g. performance implications as I know that has come up
> before when the idea of storing relevant objects on exceptions).
>
> Before the PEP was rejected by the SC, I had submitted
> https://github.com/python/cpython/pull/6271 and the last response said:
>
> You may propose a newly revised PEP which overcomes the last SC feedback.
> But without the accepted PEP, this PR can not be merged.
>
> Please clarify how can I proceed with adding some of the specified fields to
> the mentioned exceptions. Should I create a new PEP as suggested in the PR or
> should we create individual BPO issues for each exception modification.
>
> --
> Sebastian Kreft
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/4XVFFNBHXN5KBTHJGMX6ZTN6KOW4Z7UG/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/LVI7S6O5QVVTZN5A6DLYHEKGHW6EIZUH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Reviving PEP 473
I am not a Python developer, but I am very interested in this topic. While I
would definitely make use of any additional fields for exceptions as discussed,
it is already possible to find most, if not all of the information discussed in
PEP 473. To give just a concrete example taken from the PEP:
```
Friendly Console version 0.3.1. [Python version: 3.8.4]
>>> a = {'foo': 1}
>>> a['fo']
Traceback (most recent call last):
File "", line 1, in
a['fo']
KeyError: 'fo'
Did you mean foo?
>>>
>>> foo = 1
>>> fo
Traceback (most recent call last):
File "", line 1, in
fo
NameError: name 'fo' is not defined
Did you mean foo?
>>>
```
The above two examples are the actual output done by a program I work on called
friendly (formerly known as friendly-traceback) and are essentially identical
to what is given in PEP 473 as a desired outcome.
Much information about IndexError, AttributeError, etc, mentioned as desirable
in PEP 473 can already be obtained by such automated tools. Using friendly as
an example, a sample of what's possible can be found at
https://aroberge.github.io/friendly-traceback-docs/docs/html/tracebacks_en_3.8.html
Of course, having information more easily available about specific exceptions
would be welcome and make it easier and likely more error-proof to write
automated tools. But since much of the information is already available (if
one looks hard enough...), the cost of adding fields to existing exceptions
should be carefully evaluated.
André Roberge
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/LQATQLUVAZ4COI5HPS4A6DKVQ6UZ5XU7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Reviving PEP 473
Since tweaking the built-in exceptions is so far-reaching, probably at least discussing each proposed change (one at a time, not 5 at once) would be the minimum. Otherwise you could do a PEP, but once again you're looking at a PEP per exception. I think it's really going to come down to how big of an addition it is per exception, how easy it would be to have a memory leak, what the API to setting the attribute(s) would look like, etc. On Sat, Mar 13, 2021 at 1:22 PM Victor Stinner wrote: > Context: PEP 473 "Adding structured data to built-in exceptions" > proposed in 2014. > https://www.python.org/dev/peps/pep-0473/ > > Abstract: "Exceptions like AttributeError, IndexError, KeyError, > LookupError, NameError, TypeError, and ValueError do not provide all > information required by programmers to debug and better understand > what caused them. Furthermore, in some cases the messages even have > slightly different formats, which makes it really difficult for tools > to automatically provide additional information to diagnose the > problem. To tackle the former and to lay ground for the latter, it is > proposed to expand these exceptions so to hold both the offending and > affected entities." > > For example the PEP proposes to add "target" and "attribute" > attributes to AttributeError. > > PS: Please give at least the PEP title for me when you mention a PEP > only by its number, I'm unable to remember what are the 500+ PEP :-( > > Victor > > On Sat, Mar 13, 2021 at 7:49 PM Sebastian Kreft wrote: > > > > Hi dev-team, I'm reopening the discussion of PEP 473, which was closed > due to: > > > > The steering council felt the PEP was too broad and not focused enough. > Discussions about adding more attributes to built-in exceptions can > continue on the issue tracker on a per-exception basis (and obviously here > for any broader points, e.g. performance implications as I know that has > come up before when the idea of storing relevant objects on exceptions). > > > > Before the PEP was rejected by the SC, I had submitted > https://github.com/python/cpython/pull/6271 and the last response said: > > > > You may propose a newly revised PEP which overcomes the last SC feedback. > > But without the accepted PEP, this PR can not be merged. > > > > Please clarify how can I proceed with adding some of the specified > fields to the mentioned exceptions. Should I create a new PEP as suggested > in the PR or should we create individual BPO issues for each exception > modification. > > > > -- > > Sebastian Kreft > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/4XVFFNBHXN5KBTHJGMX6ZTN6KOW4Z7UG/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Night gathers, and now my watch begins. It shall not end until my death. > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/PLPUG6MFVHHHVONJK6ZHPORCQYJS5QTH/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/C7UZ7MH3TRT4M3NNYDEDNWX5WIXVOVBX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Reviving PEP 473
Context: PEP 473 "Adding structured data to built-in exceptions" proposed in 2014. https://www.python.org/dev/peps/pep-0473/ Abstract: "Exceptions like AttributeError, IndexError, KeyError, LookupError, NameError, TypeError, and ValueError do not provide all information required by programmers to debug and better understand what caused them. Furthermore, in some cases the messages even have slightly different formats, which makes it really difficult for tools to automatically provide additional information to diagnose the problem. To tackle the former and to lay ground for the latter, it is proposed to expand these exceptions so to hold both the offending and affected entities." For example the PEP proposes to add "target" and "attribute" attributes to AttributeError. PS: Please give at least the PEP title for me when you mention a PEP only by its number, I'm unable to remember what are the 500+ PEP :-( Victor On Sat, Mar 13, 2021 at 7:49 PM Sebastian Kreft wrote: > > Hi dev-team, I'm reopening the discussion of PEP 473, which was closed due to: > > The steering council felt the PEP was too broad and not focused enough. > Discussions about adding more attributes to built-in exceptions can continue > on the issue tracker on a per-exception basis (and obviously here for any > broader points, e.g. performance implications as I know that has come up > before when the idea of storing relevant objects on exceptions). > > Before the PEP was rejected by the SC, I had submitted > https://github.com/python/cpython/pull/6271 and the last response said: > > You may propose a newly revised PEP which overcomes the last SC feedback. > But without the accepted PEP, this PR can not be merged. > > Please clarify how can I proceed with adding some of the specified fields to > the mentioned exceptions. Should I create a new PEP as suggested in the PR or > should we create individual BPO issues for each exception modification. > > -- > Sebastian Kreft > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/4XVFFNBHXN5KBTHJGMX6ZTN6KOW4Z7UG/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PLPUG6MFVHHHVONJK6ZHPORCQYJS5QTH/ Code of Conduct: http://python.org/psf/codeofconduct/
