Decide if `type.__subclasses__` is part of future Python or not
Greetings, Currently `type.__subclasses__` is not documented at docs.python.org (and works in both python 2 & python 3). I would like to keep `.__subclasses__` and have it documented at docs.python.org. Is there a reason it is not documented? I realize the whole type system is going an overhaul, and the concept of what is "subclass" of another class is a complicated issue. See for example: https://github.com/python/typing/issues/135 which talks about the complexity of deciding subclassing. I think though, despite the overall, `types.__subclasses__` should be kept & documented. Thanks, Joy Diamond. 1. The google search: "site:docs.python.org __subclasses__" finds no instances of the word "__subclasses__" 2. As for what the function does, it returns the subclasses of a class: Consider the following program: class CryptographicActors(object): pass class Alice(CryptographicActors): pass class Bob(CryptographicActors): pass print("CryptographicActors subclases: %s" % CryptographicActors.__subclasses__()) help(CryptographicActors.__subclasses__) 3. It properly prints out: CryptographicActors subclases: [<class '__main__.Alice'>, <class '__main__.Bob'>] Showing the two subclasses (`Alice` and `Bob`) 4. The internal documentation explains "__subclasses__() -> list of immediate subclasses" To fully figure out what it did, I had to read the source code to Python -- which really is not the best way to figure out what a function does; hence the request to document it (and indicate it's future existence in python)
__subclasses__ is a runtime thing. As such it should probably be documented -- someone should submit a doc PR. I don't think that "overhaul" is the right word to describe what's going to happen with types in Python -- yes, we're adding optional static type checking, and yes, this will occasionally result in changed recommendations for how the language should be used or how APIs should be designed, but no, this does not mean that we're planning to deprecate or remove existing runtime features. On Mon, Oct 29, 2018 at 11:12 AM Joy Diamond <python.gem@gmail.com> wrote:
Greetings,
Currently `type.__subclasses__` is not documented at docs.python.org (and works in both python 2 & python 3).
I would like to keep `.__subclasses__` and have it documented at docs.python.org.
Is there a reason it is not documented?
I realize the whole type system is going an overhaul, and the concept of what is "subclass" of another class is a complicated issue.
See for example: https://github.com/python/typing/issues/135 which talks about the complexity of deciding subclassing.
I think though, despite the overall, `types.__subclasses__` should be kept & documented.
Thanks,
Joy Diamond.
1. The google search: "site:docs.python.org __subclasses__" finds no instances of the word "__subclasses__"
2. As for what the function does, it returns the subclasses of a class:
Consider the following program:
class CryptographicActors(object): pass class Alice(CryptographicActors): pass class Bob(CryptographicActors): pass
print("CryptographicActors subclases: %s" % CryptographicActors.__subclasses__())
help(CryptographicActors.__subclasses__)
3. It properly prints out:
CryptographicActors subclases: [<class '__main__.Alice'>, <class '__main__.Bob'>]
Showing the two subclasses (`Alice` and `Bob`)
4. The internal documentation explains "__subclasses__() -> list of immediate subclasses"
To fully figure out what it did, I had to read the source code to Python -- which really is not the best way to figure out what a function does; hence the request to document it (and indicate it's future existence in python) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
Thanks for clarification that `type.__subclasses__` is remaining. I submitted a bug request to document `type.__subclasses__` URL: https://bugs.python.org/issue35106 (Hopefully I did it correctly, as I am just learning how to submit python bugs). On Mon, Oct 29, 2018 at 2:15 PM Guido van Rossum <guido@python.org> wrote:
__subclasses__ is a runtime thing. As such it should probably be documented -- someone should submit a doc PR. I don't think that "overhaul" is the right word to describe what's going to happen with types in Python -- yes, we're adding optional static type checking, and yes, this will occasionally result in changed recommendations for how the language should be used or how APIs should be designed, but no, this does not mean that we're planning to deprecate or remove existing runtime features.
On Mon, Oct 29, 2018 at 11:12 AM Joy Diamond <python.gem@gmail.com> wrote:
Greetings,
Currently `type.__subclasses__` is not documented at docs.python.org (and works in both python 2 & python 3).
I would like to keep `.__subclasses__` and have it documented at docs.python.org.
Is there a reason it is not documented?
I realize the whole type system is going an overhaul, and the concept of what is "subclass" of another class is a complicated issue.
See for example: https://github.com/python/typing/issues/135 which talks about the complexity of deciding subclassing.
I think though, despite the overall, `types.__subclasses__` should be kept & documented.
Thanks,
Joy Diamond.
1. The google search: "site:docs.python.org __subclasses__" finds no instances of the word "__subclasses__"
2. As for what the function does, it returns the subclasses of a class:
Consider the following program:
class CryptographicActors(object): pass class Alice(CryptographicActors): pass class Bob(CryptographicActors): pass
print("CryptographicActors subclases: %s" % CryptographicActors.__subclasses__())
help(CryptographicActors.__subclasses__)
3. It properly prints out:
CryptographicActors subclases: [<class '__main__.Alice'>, <class '__main__.Bob'>]
Showing the two subclasses (`Alice` and `Bob`)
4. The internal documentation explains "__subclasses__() -> list of immediate subclasses"
To fully figure out what it did, I had to read the source code to Python -- which really is not the best way to figure out what a function does; hence the request to document it (and indicate it's future existence in python) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido)
29.10.18 20:11, Joy Diamond пише:
Currently `type.__subclasses__` is not documented at docs.python.org <http://docs.python.org> (and works in both python 2 & python 3).
I would like to keep `.__subclasses__` and have it documented at docs.python.org <http://docs.python.org>.
Is there a reason it is not documented?
It is documented. https://docs.python.org/3/library/stdtypes.html#class.__subclasses__
Thanks, Storchaka for finding the documentation. Though it is really annoying I could not find it with a google search... I looked really hard before taking the time to write my message. Sorry to bother everyone with this. On Mon, Oct 29, 2018 at 2:22 PM Serhiy Storchaka <storchaka@gmail.com> wrote:
29.10.18 20:11, Joy Diamond пише:
Currently `type.__subclasses__` is not documented at docs.python.org <http://docs.python.org> (and works in both python 2 & python 3).
I would like to keep `.__subclasses__` and have it documented at docs.python.org <http://docs.python.org>.
Is there a reason it is not documented?
It is documented.
https://docs.python.org/3/library/stdtypes.html#class.__subclasses__
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 10/29/2018 2:25 PM, Joy Diamond wrote:
Thanks, Storchaka for finding the documentation.
Though it is really annoying I could not find it with a google search...
Next time, start with our excellent index, which includes a page for words starting with '_'. There is another page for symbols, which are impossible to lookup on Google. -- Terry Jan Reedy
participants (4)
-
Guido van Rossum
-
Joy Diamond
-
Serhiy Storchaka
-
Terry Reedy