Collin Winter wrote:
> On 6/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 6/3/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> > Collin Winter wrote:
>> > > Idea: what if Python's -O option caused PySequence_Contains() to
>> > > convert all errors into False return values?
>> >
>> > It woul
On 6/4/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 6/3/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Collin Winter wrote:
> > > Idea: what if Python's -O option caused PySequence_Contains() to
> > > convert all errors into False return values?
> >
> > It would certainly give me an uneasy
On 6/3/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Collin Winter wrote:
> > Idea: what if Python's -O option caused PySequence_Contains() to
> > convert all errors into False return values?
>
> It would certainly give me an uneasy feeling if a command-line switch
> caused such a change in semanti
On 6/3/06, Collin Winter <[EMAIL PROTECTED]> wrote:
> My question is this: maybe set/frozenset.__contains__ (as well as
> dict.__contains__, etc) should catch such TypeErrors and convert them
> to a return value of False? It makes sense that "{} in frozenset([(1,
> 2, 3])" should be False, since un
Collin Winter wrote:
> I recently submitted a patch that would optimise "in (5, 6, 7)" (ie,
> "in" ops on constant tuples) to "in frozenset([5, 6, 7])". Raymond
> Hettinger rejected (rightly) the patch since it's not semantically
> consistent. Quoth:
>
>>> Sorry, this enticing idea has already bee
I recently submitted a patch that would optimise "in (5, 6, 7)" (ie,
"in" ops on constant tuples) to "in frozenset([5, 6, 7])". Raymond
Hettinger rejected (rightly) the patch since it's not semantically
consistent. Quoth:
>> Sorry, this enticing idea has already been explored and
>> rejected. Thi
