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/027448.html below:

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

[Python-Dev] string.find() again (was Re: timsort for jython)Steve Holden sholden@holdenweb.com
Tue, 6 Aug 2002 07:56:21 -0400
[Samuele Pedroni]
>
> [Greg Ewing]
> >I thought Guido was against having "in" do anything
> >other than membership tests, but his last message sounded
> >like he was changing his mind.
>
> If
>
> "thon" in "python"
>
> then why not
>
> [1,2] in [0,1,2,3]
>
> (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].

> 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!

> Either python grows a new subset/subseq operator
> but probably this is overkill (keyword issue, new
> __magic__ method, not meaningful, con
> venient for a lot of types)
>
> or strings (etc) should simply grow a new
> method with an appropriate name.
>
> "py"-in-"python"-is-dark-side-sexy-ly y'rs - Samuele Pedroni.
>
>
Consistency apparently loses out to pragmatism in this case.

regards
-----------------------------------------------------------------------
Steve Holden                                 http://www.holdenweb.com/
Python Web Programming                http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------







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