steve at REMOVE.THIS.cybersource.com.au
Thu Jul 5 04:06:11 EDT 2007
On Wed, 04 Jul 2007 23:53:15 -0400, David Abrahams wrote:
> on Wed Jul 04 2007, "Steven D'Aprano" <steve-AT-REMOVE.THIS.cybersource.com.au> wrote:
>> On Wed, 04 Jul 2007 14:37:34 +0000, Marc 'BlackJack' Rintsch wrote:
>>> On Wed, 04 Jul 2007 09:59:24 -0400, David Abrahams wrote:
>>>> Here's an implementation of the functionality I propose, as a
>>>> free-standing function:
>>>> def intersects(s1,s2):
>>>> if len(s1) < len(s2):
>>>> for x in s1:
>>>> if x in s2: return True
>>>> for x in s2:
>>>> if x in s1 return True
>>>> return False
>>> In Python 2.5 this can be written a bit more concise:
>>> def intersects(set_a, set_b):
>>> if len(set_a) < len(set_b):
>>> set_a, set_b = set_b, set_a
>>> return any(item in set_a for item in set_b)
>> I'd rather see sets gain an method "isintersect()"
> And why is that a good name? It's not even grammatical.
Neither is "It's not even grammatical", but all but purists use it
A common Python convention is to have test functions named something
like "isfoo", e.g. str.isdigit(), isspace(), islower() etc. They're not
exactly grammatical either, e.g. isdigit() should actually be "contains
one or more digits, and nothing but digits". (Presumably the pedantically
correct name was rejected as being too long.) I was just following that
My main feeling is that any such function should be a set method rather
than a built-in function like len(). The name change was comparatively
>> with the functionality than the language to gain a built-in
> How is a method on sets not a built-in function? Anyway, such a
> method is what I'm proposing.
Although they are similar, methods are not identical to functions, even
if many of us, myself included, often use the terms interchangeably.
len() is a built-in function. str.lower() is a method of strings. I'd
prefer to see intersects() be a method of sets than a built-in function,
and I think you'd have a much better chance of getting it approved as a
method than as a function, but I could be wrong.
>> However, there's a very subtle flaw in the idea. While "the intersection"
>> of two sets is well-defined, "these two sets intersect" is (surprisingly!)
>> _not_ well-defined.
> Depends how you define it.
Exactly my point.
> I define it as "has a non-empty intersection," which is pretty obviously
I didn't say it was a bad choice, only that it isn't the only choice.
More information about the Python-list