On Sat, Oct 29, 2016 at 8:36 AM, Sven R. Kunze wrote:
> Another issue I encounter regularly are things like:
>
func(mylist[i], mylist2[j])
>
> IndexError: list index out of range
>
>
> So, which are the list and index that cause the error?
+1. Showing the list's contents might be problematic
Great idea!
Another issue I encounter regularly are things like:
>>> func(mylist[i], mylist2[j])
IndexError: list index out of range
So, which are the list and index that cause the error?
On 25.10.2016 00:07, Ryan Gonzalez wrote:
I personally find it kind of annoying when you have code li
Yeah, I just checked the source and tried changing it. Seems to work well.
On Tue, Oct 25, 2016 at 8:11 PM, Steven D'Aprano
wrote:
> On Tue, Oct 25, 2016 at 04:55:21PM -0500, Ryan Gonzalez wrote:
> > Also, as an extension of this idea, would it be possible to improve
> errors
> > like this:
> >
On Tue, Oct 25, 2016 at 12:17:56PM -0700, Nathaniel Smith wrote:
> I get that this list's default is to push
> back on proposed changes, and it's a good principle in general, but
> "improved error messages" are *really* cheap. The bar should be pretty
> low, IMO.
I think its even lower than most
On Tue, Oct 25, 2016 at 04:55:21PM -0500, Ryan Gonzalez wrote:
> Also, as an extension of this idea, would it be possible to improve errors
> like this:
>
>
> class X: pass
> X() # object() takes no parameters
>
>
> to show the actual type instead of just 'object'?
My wild guess is that the ca
Also, as an extension of this idea, would it be possible to improve errors
like this:
class X: pass
X() # object() takes no parameters
to show the actual type instead of just 'object'?
On Tue, Oct 25, 2016 at 4:48 PM, Ryan Gonzalez wrote:
> So, based on everyone's feedback, I just created th
So, based on everyone's feedback, I just created this:
http://bugs.python.org/issue28536
On Mon, Oct 24, 2016 at 5:07 PM, Ryan Gonzalez wrote:
> I personally find it kind of annoying when you have code like this:
>
>
> x = A(1, B(2, 3))
>
>
> and Python's error message looks like this:
>
>
> Ty
On Tue, Oct 25, 2016 at 6:58 AM, Chris Angelico wrote:
> > >>> tuple(foo)
> >
> > TypeError: 'int' object is not iterable
> >
> > No raiser, no value given. It's hard to find out what's the problem is.
> The
> > biggest issue here is that if you have a long line with tuple() in the
> > mi
On 25 October 2016 at 20:17, Nathaniel Smith wrote:
> I get that this list's default is to push
> back on proposed changes, and it's a good principle in general, but
> "improved error messages" are *really* cheap. The bar should be pretty
> low, IMO. If someone's willing to do the work to make the
On Tue, Oct 25, 2016 at 6:20 AM, Michel Desmoulin
wrote:
> Some things deserve a big explanation to solve the problem. It would be nice
> to add a link to official tutorial in the documentation.
>
> E.G, encoding is a big one:
>
>In [8]: b'é' + 'é'
> File "", line 1
>b'é' + 'é'
>
On Tue, Oct 25, 2016 at 6:58 AM, Chris Angelico wrote:
> On Wed, Oct 26, 2016 at 12:20 AM, Michel Desmoulin
> wrote:
>> list, set and tuple less not as good:
>>
>> >>> tuple(foo)
>>
>> TypeError: 'int' object is not iterable
>>
>> No raiser, no value given. It's hard to find out what's th
On 25 October 2016 at 23:20, Michel Desmoulin wrote:
> Should we make a PEP with all of those ?
No, incrementally improving error messages doesn't require PEP level
advocacy - it just requires folks doing the development and review
work of updating them without breaking anything, and adjusting th
On Wed, Oct 26, 2016 at 12:20 AM, Michel Desmoulin
wrote:
> list, set and tuple less not as good:
>
> >>> tuple(foo)
>
> TypeError: 'int' object is not iterable
>
> No raiser, no value given. It's hard to find out what's the problem is. The
> biggest issue here is that if you have a long l
Thos are great idea. I love the current trend of trying to give better
error messages.
Another pet peave of mine: TypeError not providing at least 'raiser'
'accepted type', 'given value' and 'given value type'.
E.G, int() does an ok job:
>>> int(foo)
ValueError: invalid literal for
Also, for something like this:
In [1]: class A:
...: pass
...:
In [2]: A(x=2)
---
TypeError Traceback (most recent call last)
in ()
> 1 A(x=2)
TypeError: object() takes no param
I was thinking of posting something like the first suggestion myself. Both
would be a great additions.
On Monday, October 24, 2016 at 6:10:52 PM UTC-4, Ryan Gonzalez wrote:
>
> I personally find it kind of annoying when you have code like this:
>
>
> x = A(1, B(2, 3))
>
>
> and Python's error me
I personally find it kind of annoying when you have code like this:
x = A(1, B(2, 3))
and Python's error message looks like this:
TypeError: __init__() takes 1 positional argument but 2 were given
It doesn't give much of a clue to which `__init__` is being called. At all.
The idea: when sh
17 matches
Mail list logo
