Re: [Python-ideas] Arguments to exceptions

2017-07-06 Thread Jeff Walker
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

2017-07-06 Thread Nick Coghlan
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

2017-07-06 Thread Greg Ewing
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

2017-07-06 Thread Mark E. Haase
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

2017-07-06 Thread Paul Moore
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

2017-07-06 Thread Neil Girdhar
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

2017-07-06 Thread Mark E. Haase
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

2017-07-06 Thread Chris Angelico
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

2017-07-06 Thread Mark E. Haase
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] [off topic] Allow function to return multiple values

2017-07-06 Thread Chris Barker
On Wed, Jul 5, 2017 at 12:48 PM, Case Van Horsen wrote: > [veering off-topic] > > I've implemented mutable integers as part of the gmpy2 library. The > eXperimental MPZ (xmpz) type breaks many of the normal rules. > looks like you've added a lot more than mutability :-) >

Re: [Python-ideas] Arguments to exceptions

2017-07-06 Thread 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 intended to > > Specifically Ken started by saying that it should not be necessary to parse > the > messages to get the