"in"consistency?

David C. Ullrich dullrich at sprynet.com
Wed Jul 9 13:22:47 EDT 2008


In article <mailman.159.1215543188.20628.python-list at python.org>,
 Terry Reedy <tjreedy at udel.edu> wrote:

> David C. Ullrich wrote:
> > In article <mailman.137.1215480143.20628.python-list at python.org>,
> >  Terry Reedy <tjreedy at udel.edu> wrote:
> 
> >>> Is there a reason for the inconsistency? I would
> >>> have thought "in" would check for elements of a
> >>> sequence, regardless of what sort of sequence it was...
> >> It is not an inconsistency but an extension corresponding to the 
> >> limitation of what an string element can be.
> > 
> > It's an inconsistency. That doesn't mean it's a bad thing or that
> > I want my money back. It may well be a reasonable inconsistency -
> > strings _can_ work that way while it's clear lists had better not.
> > But it's an inconsistency.
> 
> To decisively argue 'inconsistency' as factual or not, versus us having 
> divergent opinions, you would have to supply a technical definition ;-) 
>   The math definition of 'leading to a contradiction' in the sense of 
> being able to prove False is True, does not seem to apply here.
> 
> However,
> a) In common English, 'in' and 'contains', applied to strings of 
> characters (text), is understood as applying to substrings that appear 
> in the text.  This is also true of many other programming languages. 
> 'Dictionary' contains 'diction'.  This is even the basis of various word 
> games.
> b) Python otherwise allows operators to vary in meaning for different 
> classes.
> 
> In any case, back to your original question: the extension of meaning, 
> 'inconsistent' or not, was deliberated and adopted on the basis that the 
> usefulness of the extension would outweigh the confusion wrought by the 
> class-specific nature of the extension.  (In other words, threads such 
> as this *were* anticipated ;-)

I wasn't saying that the fact that the behavior of "in" for
strings is inconsistent with the behavior for lists was a bad
thing - I was just asking about the reason for it.

(I also wasn't claiming that it was inconsistent with the
common English usage of "in"...)

People have pointed out that "in" for strings _can_ work that
way, while (of course) "in" for lists had better not. That's
fine.

> Terry Jan Reedy

-- 
David C. Ullrich



More information about the Python-list mailing list