Re: [Python-ideas] Arguments to exceptions

First, I would like to make it clear that I am not claiming that the current design of standard Exceptions cannot be improved, nor do I necessarily have a problem with doing it at the BaseException level. My argument has always been directed to the issue of "does changing BaseException actually

Re: [Python-ideas] Arguments to exceptions

On 17 July 2017 at 04:59, Ken Kundert wrote: > Nick, > I see. The Python C interface provides a very simple way of raising an > exception in the case where the exception is only passed one argument, the > error > message. It even makes it easy to interpolate

Re: [Python-ideas] Arguments to exceptions

15.07.2017, 18:33, "Chris Angelico" : > On Sun, Jul 16, 2017 at 10:12 AM, Jeff Walker > wrote: >>  The first problem is that there is no direct access to the components that >> make up the error in some of the standard Python exceptions. >> >>  

Re: [Python-ideas] Arguments to exceptions

Nick, I see. The Python C interface provides a very simple way of raising an exception in the case where the exception is only passed one argument, the error message. It even makes it easy to interpolate arguments into that error message. If it is important to include other arguments, as

Re: [Python-ideas] Arguments to exceptions

On 16 July 2017 at 10:12, Jeff Walker wrote: > Sorry Stephen (and Steven). I'll do better next time. > > The way I see it there are two problems, and the second causes the first. > > The first problem is that there is no direct access to the components that > make up

Re: [Python-ideas] Arguments to exceptions

Sorry Stephen (and Steven). I'll do better next time. The way I see it there are two problems, and the second causes the first. The first problem is that there is no direct access to the components that make up the error in some of the standard Python exceptions. >>> foo Traceback

Re: [Python-ideas] Arguments to exceptions

On Sun, Jul 16, 2017 at 10:12 AM, Jeff Walker wrote: > The first problem is that there is no direct access to the components that > make up the error in some of the standard Python exceptions. > > >>> foo > Traceback (most recent call last): > File "",

Re: [Python-ideas] Arguments to exceptions

Jeff Walker writes: > Stephen, Mr. d'Aprano is a "Steven." I'm a "Stephen". We both go by "Steve". And you replied to Chris, not to Steve. It's worth being careful about these things. I don't see what I would consider satisfactory, concise answers to your questions about Steve's claims about

Re: [Python-ideas] Arguments to exceptions

On 7 July 2017 at 22:23, Koos Zevenhoven wrote: > On Fri, Jul 7, 2017 at 7:28 AM, Nick Coghlan wrote: >> >> >> As a result, our advice is to *avoid* trying to come up with systemic >> fixes for structured exception handling, and instead focus on specific >>

Re: [Python-ideas] Arguments to exceptions

On Fri, Jul 7, 2017 at 7:28 AM, Nick Coghlan wrote: > > As a result, our advice is to *avoid* trying to come up with systemic > fixes for structured exception handling, and instead focus on specific > use cases of "I want *this* exception type to have *that* attribute > for

Re: [Python-ideas] Arguments to exceptions

On 7 July 2017 at 04:54, Jeff Walker wrote: > Here is an example: > > class NameError(BaseException): > pass > > try: > raise NameError('welker', db='users', template='{0}: unknown {db}.') > except NameError as e: > unknown_name =

Re: [Python-ideas] Arguments to exceptions

06.07.2017, 13:00, "Steven D'Aprano" : > What prevents the programmer from writing this? > > raise NameError(nym=s, template="name '{nym}' is not defined.") > > Or any other keyword name for that matter. Since the exception class > accepts arbitrary keyword arguments, we have

Re: [Python-ideas] Arguments to exceptions

Paul, I am having trouble understanding your response. 06.07.2017, 03:58, "Paul Moore" : > On 6 July 2017 at 02:53, Jeff Walker wrote: >>  Could you please expand on these statements: >> >>>   the idea doesn't actually solve the problem it is

Re: [Python-ideas] Arguments to exceptions

On 7 July 2017 at 10:26, Greg Ewing wrote: > Paul Moore wrote: >> >> But no-one manually raises NameError, so Ken's example wouldn't work >> with "real" NameErrors. > > Part of his suggestion was that core and stdlib code would > move towards using attributes. The

Re: [Python-ideas] Arguments to exceptions

Paul Moore wrote: But no-one manually raises NameError, so Ken's example wouldn't work with "real" NameErrors. Part of his suggestion was that core and stdlib code would move towards using attributes. The NameError example makes sense in that context. -- Greg

Re: [Python-ideas] Arguments to exceptions

On Thu, Jul 6, 2017 at 2:56 PM, Steven D'Aprano wrote: > > Maybe I'm misunderstanding you, but the proposal has a clear example of > > raising NameError and getting the name attribute from the exception > > instance: > > > > try: > > raise NameError(name=name,

Re: [Python-ideas] Arguments to exceptions

On 6 July 2017 at 18:59, Mark E. Haase wrote: > On Thu, Jul 6, 2017 at 5:58 AM, Paul Moore wrote: >> >> To use the (already >> >> over-used) NameError example, Ken's proposal doesn't include any >> change to how NameError exceptions are raised to store the

Re: [Python-ideas] Arguments to exceptions

This is a good example. I like this idea. I think that a good place to start would be setting the right example in the standard library: IndexError could have the offending index, KeyError the offending key, TypeError the offending type, etc. On Monday, July 3, 2017 at 3:49:23 PM UTC-4, Jeff

Re: [Python-ideas] Arguments to exceptions

On Thu, Jul 6, 2017 at 5:58 AM, Paul Moore wrote: > To use the (already > over-used) NameError example, Ken's proposal doesn't include any > change to how NameError exceptions are raised to store the name > separately on the exception. > Maybe I'm misunderstanding you, but

Re: [Python-ideas] Arguments to exceptions

On Fri, Jul 7, 2017 at 3:30 AM, Mark E. Haase wrote: > On Wed, Jul 5, 2017 at 9:22 PM, Chris Angelico wrote: >> >> For what it's worth, I'm in favour of Steven's "too negative" approach >> - or rather, I don't think his style is too negative. Yes, it's a bit

Re: [Python-ideas] Arguments to exceptions

On Wed, Jul 5, 2017 at 9:22 PM, Chris Angelico wrote: > For what it's worth, I'm in favour of Steven's "too negative" approach > - or rather, I don't think his style is too negative. Yes, it's a bit > rough and uncomfortable to be on the receiving end of it, but it's > exactly

Re: [Python-ideas] Arguments to exceptions

On 6 July 2017 at 02:53, Jeff Walker wrote: > Could you please expand on these statements: > >> the idea doesn't actually solve the problem it is intended to > > Specifically Ken started by saying that it should not be necessary to parse > the > messages to get the

Re: [Python-ideas] Arguments to exceptions

Stephen, These statements do not ring true to me. I have been following the conversation closely and I have not seen support for any of them. Perhaps I missed it. Could you please expand on these statements: > the idea doesn't actually solve the problem it is intended to Specifically Ken

Re: [Python-ideas] Arguments to exceptions

On Thu, Jul 06, 2017 at 03:32:21AM +1000, Steven D'Aprano wrote: > On Wed, Jul 05, 2017 at 04:12:29PM +, Ed Kellett wrote: > > Hi, > > > > On Wed, 5 Jul 2017 at 16:41 Steven D'Aprano wrote: > > > > > and more. Third parties *are* providing rich exception APIs where it >

Re: [Python-ideas] Arguments to exceptions

On Thu, Jul 6, 2017 at 10:46 AM, Jeff Walker wrote: > I am one of those that also find you to be too negative. I find your > critiques to > be useful. You often raise issues that had not occurred to me. But then you > go further an make pronouncements which I think go

Re: [Python-ideas] Arguments to exceptions

On 2017-07-05 04:36, Steven D'Aprano wrote: On Tue, Jul 04, 2017 at 11:37:51PM -0400, Terry Reedy wrote: I personally been on the side of wanting richer exceptions. Could you explain what you would use them for? Ken has give two use-cases which I personally consider are relatively niche, and

Re: [Python-ideas] Arguments to exceptions

On Wed, Jul 05, 2017 at 04:12:29PM +, Ed Kellett wrote: > Hi, > > On Wed, 5 Jul 2017 at 16:41 Steven D'Aprano wrote: > > > and more. Third parties *are* providing rich exception APIs where it > > makes sense to do so, using the interface encouraged by PEP 352 (named > >

Re: [Python-ideas] Arguments to exceptions

I agree with Ken for the need to make rich exceptions easy to write, but I do not know enough to say if changing BaseException to support this is a good idea; I made my own error reporting library to do this: For example, to define a new exception type with a `name` attribute: raise

Re: [Python-ideas] Arguments to exceptions

Hi, On Wed, 5 Jul 2017 at 16:41 Steven D'Aprano wrote: > and more. Third parties *are* providing rich exception APIs where it > makes sense to do so, using the interface encouraged by PEP 352 (named > attributes), without needing a default "StructuredException" in the >

Re: [Python-ideas] Arguments to exceptions

On Wed, Jul 05, 2017 at 03:29:35PM +0200, Matthias Bussonnier wrote: > Hi all, > > I want to point out that if it's not common to dispatch on values of > exceptions it might be **because** it is hard to do or to know wether > an exception will be structured or not. It "might be" for a lot of

Re: [Python-ideas] Arguments to exceptions

Hi all, I want to point out that if it's not common to dispatch on values of exceptions it might be **because** it is hard to do or to know wether an exception will be structured or not. If Exceptions were by default more structured, if CPython would provide a default "StructuredException", or

Re: [Python-ideas] Arguments to exceptions

On Tue, Jul 04, 2017 at 11:37:51PM -0400, Terry Reedy wrote: > I personally been on the side of wanting richer exceptions. Could you explain what you would use them for? Ken has give two use-cases which I personally consider are relatively niche, and perhaps even counter-productive: -

Re: [Python-ideas] Arguments to exceptions

Terry Reedy wrote: > Alternate proposal: give the NameError class a .name instance method > that extracts the name from the message. This should not increase the > time to create an instance. You would then write 'err.name()' instead > of 'err.name'. For 3.6 > > def name(self): > msg =

Re: [Python-ideas] Arguments to exceptions

Terry Reedy wrote: It occurs to me that if the exception object has no reference to any python object, then all would be identical and only one cached instance should be needed. I don't think that's true now that exceptions get tracebacks attached to them. -- Greg

Re: [Python-ideas] Arguments to exceptions

On 7/5/2017 12:21 AM, Terry Reedy wrote: On 7/4/2017 6:31 PM, Greg Ewing wrote: Terry Reedy wrote: Attaching a *constant* string is very fast, to the consternation of people who would like the index reported. Actually, the constant string should be attached to the class, so there is no time

Re: [Python-ideas] Arguments to exceptions

On 7/4/2017 8:08 PM, Ken Kundert wrote: On Tue, Jul 04, 2017 at 04:54:11PM -0400, Terry Reedy wrote: There have been many proposals for what we might call RichExceptions, with more easily access information. But as Raymond Hettinger keeps pointing out, Python does not use exceptions only for

Re: [Python-ideas] Arguments to exceptions

On 7/4/2017 6:31 PM, Greg Ewing wrote: Terry Reedy wrote: Attaching a *constant* string is very fast, to the consternation of people who would like the index reported. Actually, the constant string should be attached to the class, so there is no time needed. Seems to me that storing the

Re: [Python-ideas] Arguments to exceptions

On 7/4/2017 5:47 PM, Brendan Barnwell wrote: On 2017-07-04 13:54, Terry Reedy wrote: There have been many proposals for what we might call RichExceptions, with more easily access information. But as Raymond Hettinger keeps pointing out, Python does not use exceptions only for (hopefully rare)

Re: [Python-ideas] Arguments to exceptions

On Tue, Jul 04, 2017 at 05:08:57PM -0700, Ken Kundert wrote: > On Tue, Jul 04, 2017 at 04:54:11PM -0400, Terry Reedy wrote: > > There have been many proposals for what we might call > > RichExceptions, with more easily access information. But as Raymond > > Hettinger keeps pointing out, Python

Re: [Python-ideas] Arguments to exceptions

On Tue, Jul 04, 2017 at 04:54:11PM -0400, Terry Reedy wrote: > There have been many proposals for what we might call > RichExceptions, with more easily access information. But as Raymond > Hettinger keeps pointing out, Python does not use exceptions only > for (hopefully rare) errors. It also

Re: [Python-ideas] Arguments to exceptions

Terry Reedy wrote: Attaching a *constant* string is very fast, to the consternation of people who would like the index reported. Seems to me that storing the index as an attribute would help with this. It shouldn't be much slower than storing a constant string, and formatting the message would

Re: [Python-ideas] Arguments to exceptions

If a method, why not a property? On Jul 4, 2017 2:41 PM, "Terry Reedy" wrote: > On 7/4/2017 3:32 PM, David Mertz wrote: > >> I don't see the usefulness rich exception data as at all as limited as >> this. Here's some toy code that shows a use: >> >> >> >> >> # For some

Re: [Python-ideas] Arguments to exceptions

On 2017-07-04 13:54, Terry Reedy wrote: There have been many proposals for what we might call RichExceptions, with more easily access information. But as Raymond Hettinger keeps pointing out, Python does not use exceptions only for (hopefully rare) errors. It also uses them as signals for flow

Re: [Python-ideas] Arguments to exceptions

On 7/4/2017 3:32 PM, David Mertz wrote: I don't see the usefulness rich exception data as at all as limited as this. Here's some toy code that shows a use: # For some reason, imports might not be ready immediately # Maybe flaky network drive, maybe need to install modules, etc # The

Re: [Python-ideas] Arguments to exceptions

On 7/4/2017 10:03 AM, Steven D'Aprano wrote: On Mon, Jul 03, 2017 at 01:59:02AM -0700, Ken Kundert wrote: I think in trying to illustrate the existing behavior I made things more confusing than they needed to be. Let me try again. I understood you the first time :-) I agree that scraping

Re: [Python-ideas] Arguments to exceptions

I don't see the usefulness rich exception data as at all as limited as this. Here's some toy code that shows a use: # For some reason, imports might not be ready immediately # Maybe flaky network drive, maybe need to install modules, etc # The overall program can do things too make them

Re: [Python-ideas] Arguments to exceptions

On Sun, Jul 02, 2017 at 12:19:54PM -0700, Ken Kundert wrote: > class BaseException: > def __init__(self, *args, **kwargs): > self.args = args > self.kwargs = kwargs > > def __str__(self): > template = self.kwargs.get('template') >

Re: [Python-ideas] Arguments to exceptions

On Wed, Jul 05, 2017 at 12:10:26AM +1000, Steven D'Aprano wrote: > I think Ken is right that *if* this problem is worth solving, we should > solve it in BaseException (or at least StandardException), Oops, I forgot that StandardException is gone. And it used to be spelled StandardError. --

Re: [Python-ideas] Arguments to exceptions

On Mon, Jul 03, 2017 at 10:44:20PM +0100, Paul Moore wrote: > > 1. Change BaseException. This allows people to pass the components > > to the message without ruining str(e). > > I dispute this is the essential place to start. If nothing else, the > proposed approach encourages people to use

Re: [Python-ideas] Arguments to exceptions

On Mon, Jul 03, 2017 at 01:46:14PM -0600, Jeff Walker wrote: > Consider this example: > > import json > > > > >>> s = '{"abc": 0,

Re: [Python-ideas] Arguments to exceptions

On Mon, Jul 03, 2017 at 06:29:05AM -0400, Juancarlo Añez wrote: > On Mon, Jul 3, 2017 at 4:59 AM, Ken Kundert > wrote: > > > That is the problem. To write the error handler, I need the misspelled > > name. > > The only way to get it is to extract it from the error

Re: [Python-ideas] Arguments to exceptions

On Mon, Jul 03, 2017 at 01:59:02AM -0700, Ken Kundert wrote: > I think in trying to illustrate the existing behavior I made things more > confusing than they needed to be. Let me try again. I understood you the first time :-) I agree that scraping the name from the NameError exception is a

Re: [Python-ideas] Arguments to exceptions

On 4 July 2017 at 06:08, Nick Coghlan wrote: > On 4 July 2017 at 09:46, Greg Ewing wrote: >> Paul Moore wrote: >>> >>> As noted, I disagree that people are not passing components because >>> str(e) displays them the way it does. But we're both

Re: [Python-ideas] Arguments to exceptions

On 4 July 2017 at 09:46, Greg Ewing wrote: > Paul Moore wrote: >> >> As noted, I disagree that people are not passing components because >> str(e) displays them the way it does. But we're both just guessing at >> people's motivations, so there's little point in

Re: [Python-ideas] Arguments to exceptions

All, My primary concern is gaining access to the components that make up the messages. I am not hung up on the implementation. I just proposed the minimum that I thought would resolve the issue and introduce the least amount of risk. Concerning MRAB's idea of making the named arguments

Re: [Python-ideas] Arguments to exceptions

Paul Moore wrote: As noted, I disagree that people are not passing components because str(e) displays them the way it does. But we're both just guessing at people's motivations, so there's little point in speculating. I've no doubt that the current situation encourages people to be lazy -- I

Re: [Python-ideas] Arguments to exceptions

On 2017-07-03 22:44, Paul Moore wrote: On 3 July 2017 at 21:56, Jeff Walker wrote: Paul, Indeed, nothing gets better until people change the way they do their exceptions. Ken's suggested enhancement to BaseException does not directly solve the problem, but it

Re: [Python-ideas] Arguments to exceptions

Paul, Indeed, nothing gets better until people change the way they do their exceptions. Ken's suggested enhancement to BaseException does not directly solve the problem, but it removes the roadblocks that discourage people from passing the components to the message. Seems to me that to

Re: [Python-ideas] Arguments to exceptions

Paul, I think you are fixating too much on Ken's example. I think I understand what he is saying and I agree with him. It is a problem I struggle with routinely. It occurs in the following situations: 1. You are handling an exception that you are not raising. This could be because

Re: [Python-ideas] Arguments to exceptions

On 3 July 2017 at 20:46, Jeff Walker wrote: > I think you are fixating too much on Ken's example. I think I understand > what he > is saying and I agree with him. It is a problem I struggle with routinely. It > occurs in > the following situations: Possibly. I

Re: [Python-ideas] Arguments to exceptions

On Mon, Jul 3, 2017 at 4:59 AM, Ken Kundert wrote: > That is the problem. To write the error handler, I need the misspelled > name. > The only way to get it is to extract it from the error message. The need to > unpack information that was just packed suggests that

Re: [Python-ideas] Arguments to exceptions

On 3 July 2017 at 09:59, Ken Kundert wrote: > I think in trying to illustrate the existing behavior I made things more > confusing than they needed to be. Let me try again. > > Consider this code. > > >>> import Food > >>> try: > ... import meals >

Re: [Python-ideas] Arguments to exceptions

I think in trying to illustrate the existing behavior I made things more confusing than they needed to be. Let me try again. Consider this code. >>> import Food >>> try: ... import meals ... except NameError as e: ... name = str(e).split("'")[1] # <-- fragile code

Re: [Python-ideas] Arguments to exceptions

On Sun, Jul 02, 2017 at 12:19:54PM -0700, Ken Kundert wrote: [...] > >>> try: > ... foo > ... except Exception as e: > ... print('str:', str(e)) > ... print('args:', e.args) > str: name 'foo' is not defined > args: ("name 'foo' is not defined",) > > Notice

[Python-ideas] Arguments to exceptions

All, Here is a proposal for enhancing the way BaseException handles arguments. -Ken Rationale = Currently, the base exception class takes all the unnamed arguments passed to an exception and saves them into args. In this way they are available to the exception handler. A