This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author levkivskyi
Recipients Arfrever, gvanrossum, larry, levkivskyi, ncoghlan, ned.deily, rhettinger, yan12125
Date 2016-10-03.11:41:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1475494878.99.0.615618057309.issue28339@psf.upfronthosting.co.za>
In-reply-to
Content
I have submitted a PR with one of the quick fixes upstream (to python/typing). Also I have played a bit with a more permanent fix. Here is an important observation: it is not easy to avoid adding parameterized generics to __subclasses__. For example, Node[int] should have at least one base, that base will have it in __subclasses__. The former is dynamically updated, so that we cannot "fool" it.

Also making subclass checks for all subclasses is a "deliberate act", so that it should be treated by common rules.

It looks like we have only three options:

1. Abandon the idea of raising TypeError for generics, most users expect True or False, so that some exiting code might break

2. Make __getitem__ for generics return self, so that ``Node[int] is Node`` at runtime (this is a subset of the first option).

3. Still force people not to use issubclass() with parameterized generics (this is quite bad idea and could have misleading consequences), but make an exception for existing stdlib modules abc and functools, all later additions should respect the rule.

4. Similarly to above, but just make tiny patches to abc and functools to use __origin__ in subclass checks if it is present and not None.

Which option is the right one? I would vote for the last one. This could break some (probably very small amount) existing code. So that formally speaking it is a backward incompatible change. We could go with option 1 for 3.5 and with option 4 for 3.6

Also I have found another failure in test suite with latest version from python/typing after importing typing while running ./python -c 'import runpy, typing; runpy.run_module("test")'

test test_collections failed -- Traceback (most recent call last):
  File "/Users/ivan/hg-cpython/Lib/test/test_collections.py", line 1309, in test_ByteString
    self.assertNotIsInstance(memoryview(b""), ByteString)
AssertionError: <memory at 0x113b129b8> is an instance of <class 'collections.abc.ByteString'>

This is because of this line in typing.py

ByteString.register(type(memoryview(b'')))

The fix for this is very simple, we just need to decide whether memoryview should be an instance of ByteString or not, and either remove this line or remove the failing test.

I do not have any strong opinion on this, what do you think?
History
Date User Action Args
2016-10-03 11:41:19levkivskyisetrecipients: + levkivskyi, gvanrossum, rhettinger, ncoghlan, larry, ned.deily, Arfrever, yan12125
2016-10-03 11:41:18levkivskyisetmessageid: <1475494878.99.0.615618057309.issue28339@psf.upfronthosting.co.za>
2016-10-03 11:41:18levkivskyilinkissue28339 messages
2016-10-03 11:41:18levkivskyicreate