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 to expect that it coul
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 intended to
>>
>> Specifically Ken started by say
On 7 July 2017 at 12:18, Nick Coghlan wrote:
> By contrast, we're incredibly wary of trying to enhance exception
> behaviour by way of `BaseException` changes due to our past negative
> experiences with that during the original implementation of PEP 352:
> https://www.python.org/dev/peps/pep-0352/
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 NameError example makes
> sense i
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
__
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, template="name '{name}'
On 2017-07-06 02:53, Jeff Walker wrote:
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 prob
On Thu, Jul 06, 2017 at 01:59:02PM -0400, 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 name
> > separately on t
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 name
>> separately on the exception.
>
>
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
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 the proposal has a cle
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
>> rough and uncomfortable to be on th
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 correct. All three
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 :-)
> I'm not sure how usef
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 components of the message. He
15 matches
Mail list logo
