Author terry.reedy
Recipients cvrebert, terry.reedy
Date 2009-04-18.07:29:07
SpamBayes Score 1.13936e-05
Marked as misclassified No
Message-id <1240039752.65.0.67234605717.issue5760@psf.upfronthosting.co.za>
In-reply-to
Content
As I said on the python-ideas discussion, which definitely did *not*
come to consensus, I disagree with this suggestion.  To repeat and
expand on what I said there:

1. 'unsubscriptable' could instead be changed to 'not subscriptable'.

2. 'subscription' *is* the way Python describes the use of [].
"""A subscription selects an item of a sequence (string, tuple or list)
or mapping (dictionary) object:

subscription ::=  primary "[" expression_list "]"
"""
'array subscript' (from C, for example) is a standard term used for
decades in computer languages.  It is appropriate since a[i] is one
standard single-text-line replacement for a<typographic subscript>i when
one cannot actually 'type' a subscript.  It *is* a way of representing a
subscript, just as i**j is an in-line way of representing a superscript
exponent, which we still call an exponent in spite of it not being
'raised'.  Both constitute visible markup that is part of the compromise
in representing 2D typography with a 1D stream of characters.  Using '/'
for division (and fractions) is another.

3. Python error message generally do not and I think should not mention
the special method implementation that underlies surface level errors. 
In this particular case, the remedy to mistakenly trying to subscript
something is to not do that.  I think mentioning __getitem__ would be a
distraction.  One generally *cannot* just go around adding it.
History
Date User Action Args
2009-04-18 07:29:12terry.reedysetrecipients: + terry.reedy, cvrebert
2009-04-18 07:29:12terry.reedysetmessageid: <1240039752.65.0.67234605717.issue5760@psf.upfronthosting.co.za>
2009-04-18 07:29:09terry.reedylinkissue5760 messages
2009-04-18 07:29:08terry.reedycreate