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.

classification
Title: issubclass() should accept iterables in 2nd arg
Type: enhancement Stage: resolved
Components: Interpreter Core Versions: Python 3.4
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Ramchandra Apte, franck, iritkatriel, mark.dickinson, terry.reedy
Priority: normal Keywords:

Created on 2013-02-08 14:06 by Ramchandra Apte, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (7)
msg181670 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2013-02-08 14:07
kushou pointed this out on #python-dev
msg181672 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2013-02-08 14:55
What's the use case for this?  issubclass already accept tuples, just like isinstance:

>>> issubclass(bool, (int, float))
True
msg181714 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-02-09 02:59
Given isxxx(src, target_s), the proposal would seem to be to change the internal test "type(target_s) is tuple" to "hasattr(type(target_s), '__iter__'). This depends on metaclasses not having .__iter__ methods, just as type does not. However, a subclass of type that added .__iter__, for instance to iterate through all its instances (classes defined with that metaclass), would break that test. So the proposal needs a better test, that cannot become ambiguous, to be practical.

A virtue of the 'class or tuple of classes' interface is that a tuple instance is clearly not a class in itself, so there is no possible ambiguity.

It is a positive feature that isinstance and issubclass have the same signature: both or neither should be changed. The use of tuple for multiple items in 'item or items' interfaces is historical and also used elsewhere, as in exception clauses.

The meaning of
  except target_exception_s [as name]: body
is 
  if issubclass(raised_exception, target_exception_s)
      or isinstance(raised_exception, target_exception_s):
    [name = raised_exception]
    body

So to remain consistent, I think changing exception statements to allow iterables of exceptions should also be part of the proposal.

There might be something else that I am forgetting about at the moment.

While iterables might be used if Python were being written fresh today and the ambiguity problem were solved, I agree that more than esthetic satisfaction is needed to make a change.
msg181730 - (view) Author: Ramchandra Apte (Ramchandra Apte) * Date: 2013-02-09 10:35
Just so you know, I'm neutral on this idea. I think it should at least accept sequences though.
msg181737 - (view) Author: Franck Michea (franck) * Date: 2013-02-09 13:49
I am neutral on this too, it just felt odd and this is why the question raised.

Yesterday I tried to add sequences and iterables (only to issubclass but indeed it would need better testing and all) and came to a problem with sequences. The current implementation authorizes (A, (B, (C, D))) (why?) so issubclass is recursive, but if we add sequences, they could create infinite recursions if seq[0] == seq (it's the case for strings for example, where 'a' is still a sequence and 'a'[0] == 'a').

So I don't know if it's really interesting. Anyone can use tuple() on an iterable to build its tuple value, though the value is built in memory. It basically just felt odd to take only tuples but I don't know.
msg381189 - (view) Author: Irit Katriel (iritkatriel) * (Python committer) Date: 2020-11-16 23:51
Good discussion. There seems to be agreement that this should not be done.
msg381209 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2020-11-17 06:34
except ... is another instance of (exception) class or tuple of classes.
History
Date User Action Args
2022-04-11 14:57:41adminsetgithub: 61359
2020-11-17 06:34:31terry.reedysetmessages: + msg381209
2020-11-16 23:51:59iritkatrielsetstatus: open -> closed

nosy: + iritkatriel
messages: + msg381189

resolution: rejected
stage: resolved
2013-02-09 13:49:44francksetmessages: + msg181737
2013-02-09 10:35:05Ramchandra Aptesetmessages: + msg181730
2013-02-09 02:59:24terry.reedysetnosy: + terry.reedy
messages: + msg181714
2013-02-08 14:55:26mark.dickinsonsetnosy: + mark.dickinson

messages: + msg181672
versions: - Python 3.3
2013-02-08 14:12:24Ramchandra Aptesetstatus: languishing -> open
2013-02-08 14:10:02Ramchandra Aptesetstatus: open -> languishing
2013-02-08 14:08:02Ramchandra Aptesettitle: issubclass should accept iterables -> issubclass() should accept iterables in 2nd arg
2013-02-08 14:07:33Ramchandra Aptesetmessages: + msg181670
2013-02-08 14:06:55Ramchandra Aptesetcomponents: + Interpreter Core
2013-02-08 14:06:31Ramchandra Aptecreate