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
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
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,
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
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
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
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
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 :-)
>
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
11 matches
Mail list logo