Hi, attempt 2.

My system is MacOs Yosemite (10.10.5), I have installed Python 3.6.1 downloaded from the official Python website.

I was having issues while testing a custom Set implementation using the _collections_abc base MutableSet and found that my issue was apparently resolved with issue 8743. From the fix, in the attached script I would expect the and operation between my set implementation and a string to fail with a TypeError, given that string is not an instance of Set. However, the error is not raised, i.e. the print statement is executed. 

From the discussion on issue 8743, I would expect _collections_abc.py to have a test for Set instances, but is not the case (for example):

    def __and__(self, other):
        if not isinstance(other, Iterable):
            return NotImplemented
        return self._from_iterable(value for value in other if value in self)

That is, I was expecting a isinstance(other, Set) somewhere there.

In my previous post I was told my python installation was broken. However, I checked the collections_abc.py in my windows system and is the same. I am not an expert on the Python build system, but the patch in bug 8743 applies to /Lib/_abcoll.py, but I guess _collections_abc.py is generated somehow.

You don't appear to have successfully attached the script.  Can you try again please?

The patching in the issue you point to does not patch __and__, it just sets it equal to __rand__.

And rather than focusing on what lines of code you believe are missing, please provide a complete script or lines of Python code with any instructions on how to run them, the actual output you see when you run it, and what you expect the output should be.  Otherwise, we just have to guess at what the issue here is and we'll probably guess wrong.

Guess my second attempt didn't work as expected ;-).

I have attached the file now. To run just invoke the script:

$ python3 example.py
s&t did not screen-out general iterables

I would expect to see no output.

OK, thanks for supplying a concrete example.  From it, it's clear that it has nothing specific to do with Python on macOS.  Adding Raymond as maintainer of sets.

> I would expect the and operation between my set implementation 
> and a string to fail with a TypeError, given that string is 
> not an instance of Set. However, the error is not raised ...

Odd as it may seem, this isn't a bug; rather it was a deliberate design decision by GvR.  Regular sets have a intersection() method that accepts any iterable.  In contrast, the Set abstract base class doesn't have a intersection() method and instead uses __and__() to do the work.

While there is room to have debated whether that design decision was a good one, that ship sailed long ago.  Tightening the input requirement now would almost certainly break existing code and would take away needed functionality.

Alternatively, we could liberalize set.__and__ to make it accept any iterable (to match the ABC), but Guido advised against this based on his bad experiences with list.__iadd__ accepting any iterable (for example:   s = ['abc', 'def']; s += 'def').  I think he's right that such an amendment would be a bug factory.

You'll likely find a number of places where the collection ABCs differ in minor details from various concrete classes.  In almost every case, you'll find a reason for the choices that were made.  It hasn't been a problem in practice unless someone (like the OP) expects that the ABCs have higher fidelity and can used to reimplement all of the details of the related concrete class (i.e. expecting to use Set() to match all the concrete implement nuances tested in Lib/test_set.py).

Although I agree that some design decisions forge a language and sometimes these historical developments win over sounder or more "logical" arguments.

That being said, I believe (as the OP of issue 8743) that the ABC collections should comply to the API of the Python base collections. In that sense, I would expect any custom collection implemented by extending the ABC collections to be used in place of an exiting base one, without any "hiccups". Thus, the custom collection should pass all the tests in the Lib/tests.

Of course, for the moment, this would just require extra work on my part in order to implement all the magic methods and such.

If history is to win again, then at least the documentation of the ABC  collections should clearly state the subtle, but IMHO important, differences between the two.

For backward compatibility reasons, history will win.  

I'm not sure if documenting the additional restrictions of the concrete stdlib types in the ABC docs makes sense, either, since the ABCs are intentionally the minimal requirements for a concrete type to conform to the ABC.  The concrete ABC methods are really examples, even though they are also widely useful (and widely used).

I suppose someone could propose a set of tests that an implementation of an ABC type should pass, to complement the stdlib type tests.  There would probably be a lot of bikeshedding involved in such tests though, so I don't hold out great hope anything would ever get accepted for merge :)

> That being said, I believe (as the OP of issue 8743) 
> that the ABC collections should comply to the API of
> the Python base collections. 

Sorry Horacio, but your beliefs don't trump Guido's intentional design decisions.   He was the one who decided that the collections.abc.Set should have a __and__ that accepts an iterable and that it should not have the named methods (union, intersection, difference, etc).  Once released, that decision is not changeable without breaking existing code that relies on any iterable being accepted (which is a useful behavior given the absence of an union() method).   Guido also decided long ago that no class other that list would repeat its list.__iadd__ design mistake.   You can search the python-dev archives to find the discussion where it was decided that this applies to the concrete set type (i.e. that s |= 'abc' would raise a TypeError).  I happen to agree with that decision.  Though it seems to offend your sense of consistency, it does have the advantage of precluding what would likely be a common source of errors.

I'm marking this as closed.  The time to litigate API design decisions is prior to their being released.  This particular ship sailed a decade ago and has mostly worked out fine for all of our users.