Brett Cannon wrote:
> So +0 on your specific improvment and +1 for trying to think about
> newbies when writing exception messages.
The __eq__/__hash__ messages are somewhat arcane because the problem
they're describing is somewhat arcane.
Michael's suggested improvement also isn't quite right (a
Ben Finney wrote:
It's a single operation as far as the parser is concerned, so there
needs to be a single term for it. That term is “subscript”.
How about something like "does not support the [] operation".
This refers directly to the syntax involved, rather than
using a typographical term t
On Wed, Sep 23, 2009 at 5:25 PM, Antoine Pitrou wrote:
> MRAB mrabarnett.plus.com> writes:
>>
>> It's called a 'subscript' because conventional mathematical notation
>> uses subscripting. Newbies might be acquainted with the term 'index'
>> from books, where the 'value' is non-numeric. It's a bit
MRAB mrabarnett.plus.com> writes:
>
> It's called a 'subscript' because conventional mathematical notation
> uses subscripting. Newbies might be acquainted with the term 'index'
> from books, where the 'value' is non-numeric. It's a bit unfortunate
> that dicts have keys+value instead of index+va
Ben Finney wrote:
Steven D'Aprano writes:
As far as I can see, in practice, people talk about obj[i] as the item
at index i, not the item at subscript i -- the term "subscript" in
this context seems to be rare to non-existent except for the error
message.
Presumably, the same people would al
Janzert wrote:
Steven D'Aprano wrote:
On Thu, 24 Sep 2009 06:47:41 am Dino Viehland wrote:
So I am +1 on unified the message and +1 on using the "does not
support indexing" one.
I'd be +1 on the unified message as well - but it seems what that
message should be may be contentious (and quite a
Steven D'Aprano writes:
> As far as I can see, in practice, people talk about obj[i] as the item
> at index i, not the item at subscript i -- the term "subscript" in
> this context seems to be rare to non-existent except for the error
> message.
Presumably, the same people would also call ‘obj[i
Steven D'Aprano wrote:
> On Thu, 24 Sep 2009 06:47:41 am Dino Viehland wrote:
>>> So I am +1 on unified the message and +1 on using the "does not
>>> support indexing" one.
>> I'd be +1 on the unified message as well - but it seems what that
>> message should be may be contentious (and quite a bike
On Thu, 24 Sep 2009 06:47:41 am Dino Viehland wrote:
> > So I am +1 on unified the message and +1 on using the "does not
> > support indexing" one.
>
> I'd be +1 on the unified message as well - but it seems what that
> message should be may be contentious (and quite a bike shed
> discussion at tha
On Wed, Sep 23, 2009 at 14:49, Michael Foord wrote:
> Brett Cannon wrote:
>>
>> On Wed, Sep 23, 2009 at 14:19, Michael Foord
>> wrote:
>> [SNIP]
>>
>>>
>>> Also +1. I had a friend (an experienced programmer) who started using
>>> Python
>>> recently. The cryptic nature of some of the error messag
Brett Cannon wrote:
On Wed, Sep 23, 2009 at 14:19, Michael Foord wrote:
[SNIP]
Also +1. I had a friend (an experienced programmer) who started using Python
recently. The cryptic nature of some of the error messages was a sore point
with him.
Do you know which error messages? We can ch
On Wed, Sep 23, 2009 at 13:47, Dino Viehland wrote:
> Brett wrote:
>> Let's ignore history, which I bet is the reason for the distinction,
>> and just look at the error messages; does the distinction make sense
>> to a newbie? I would say no and that the "does not support indexing"
>> error messag
On Wed, Sep 23, 2009 at 14:19, Michael Foord wrote:
[SNIP]
> Also +1. I had a friend (an experienced programmer) who started using Python
> recently. The cryptic nature of some of the error messages was a sore point
> with him.
Do you know which error messages? We can change them. We have always
M.-A. Lemburg wrote:
Brett Cannon wrote:
On Tue, Sep 22, 2009 at 20:08, R. David Murray wrote:
On Wed, 23 Sep 2009 at 02:01, MRAB wrote:
Dino Viehland wrote:
Is there a reason or a rule by which CPython reports different error
message for different failures to subsc
Brett Cannon wrote:
> On Tue, Sep 22, 2009 at 20:08, R. David Murray wrote:
>> On Wed, 23 Sep 2009 at 02:01, MRAB wrote:
>>>
>>> Dino Viehland wrote:
Is there a reason or a rule by which CPython reports different error
message for different failures to subscript?
For ex
Brett wrote:
> Let's ignore history, which I bet is the reason for the distinction,
> and just look at the error messages; does the distinction make sense
> to a newbie? I would say no and that the "does not support indexing"
> error message is more useful. For expert programmers they could figure
On Tue, Sep 22, 2009 at 20:08, R. David Murray wrote:
> On Wed, 23 Sep 2009 at 02:01, MRAB wrote:
>>
>> Dino Viehland wrote:
>>>
>>> Is there a reason or a rule by which CPython reports different error
>>> message for different failures to subscript?
>>>
>>> For example:
>>>
>>> > > > set()[2]
R. David Murray wrote:
> Looking at the source, these messages are generated from abstract.c,
> and the difference appears to be whether or not the tp_as_sequence slot
> is filled in or not. If it is, but there is no sq_item method, then
> PySequence_GetItem gives the "does not support indexing" m
On Wed, 23 Sep 2009 at 02:01, MRAB wrote:
Dino Viehland wrote:
Is there a reason or a rule by which CPython reports different error
message for different failures to subscript?
For example:
> > > set()[2]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'set' object
Dino Viehland wrote:
Is there a reason or a rule by which CPython reports different error
message for different failures to subscript?
For example:
>>> set()[2]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'set' object does not support indexing
>>> class c
Is there a reason or a rule by which CPython reports different error message
for different failures to subscript?
For example:
>>> set()[2]
Traceback (most recent call last):
File "", line 1, in
TypeError: 'set' object does not support indexing
>>> class c(object): pass
...
>>> c()[2]
Traceba
21 matches
Mail list logo
