A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-August/027449.html below:

[Python-Dev] string.find() again (was Re: timsort for jython)

[Python-Dev] string.find() again (was Re: timsort for jython)Samuele Pedroni pedroni@inf.ethz.ch
Tue, 6 Aug 2002 14:12:27 +0200
[Steve Holden]
>> (it's a purely rhetorical question)
>>
>Which I also asked. But Guido pointed out htat [1, 2] may well be a member
>of a list such as [0, [1, 2], [3, 4], 5].

which just reinfornces my point below,
anyway I knew that before, even
without Guido. You were not supposed
to answer a rethorical question anyway <wink>.
I have not read the entire
unbearably long thread.

>> in general I don't think it is a good idea
>> to have "in" be a membership vs subset/subseq
>> operator depending on non ambiguity, convenience
>> or simply implementer taste,
>> because truly there are data types (ex. sets)
>> that would need both and disambiguated.
>>
>Well, it looks like you lose!

I'm not taking this personally,
the problem one operator, two potential
semantics remains.

>Consistency apparently loses out to pragmatism in this case.

What do you want "in" to do for you today? <wink><wink>.

That's my last input on the matter.

regards.

PS: these days I read python-dev through the archives,
it seems that this time I have added to redudance
department myself, oh well...




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4