[issue35083] Fix documentation for __instancecheck__
New submission from Joy Diamond :
This is a request to fix the documentation for __instancecheck__.
Please add the following:
"""
(Note that any object `x` is always considered to be an instance of
`type(x)`, and this cannot be overridden.)
"""
Consider the following program:
class M(type):
def __instancecheck__(m, t):
print('instancecheck(%s, %s)' % (m, t))
return False# LIE!
Test = M('Test', ((object,)), {})
something = Test()
print('Does *NOT* call __instancecheck__:')
print('isinstance(something, Test): %s' % isinstance(something, Test))
print()
print('Does call __instancecheck__:')
print('isinstance(0, Test): %s' % isinstance(0, Test))
Under python 2, python 3, and pypy, in all cases, the first examples does *NOT*
call __instancecheck__.
You can see the optimization here:
https://github.com/python/cpython/blob/master/Objects/abstract.c#L2397-L2405
Which reads:
int
PyObject_IsInstance(PyObject *inst, PyObject *cls)
{
_Py_IDENTIFIER(__instancecheck__);
PyObject *checker;
/* Quick test for an exact match */
if (Py_TYPE(inst) == (PyTypeObject *)cls)
return 1;
I'm fine with the optimization -- I am not suggesting to get rid of it.
I just want the documentation to match the actual implementation.
The following documentation needs to be fixed:
https://docs.python.org/2/reference/datamodel.html
https://docs.python.org/3/reference/datamodel.html
https://www.python.org/dev/peps/pep-3119/
It took me half an hour to figure out why my version of __instancecheck__ was
not working, as I tried to test it using the super simple code above ...
One of the best things about python is how accurate and consistent the
documentation is.
This request is to keep these high standards.
--
assignee: docs@python
components: Documentation
messages: 328658
nosy: docs@python, joydiamond
priority: normal
severity: normal
status: open
title: Fix documentation for __instancecheck__
type: enhancement
versions: Python 2.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue35083>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35098] Deleting __new__ does not restore previous behavior
New submission from Joy Diamond :
Related: https://bugs.python.org/issue5322
Consider the following program:
class Color(object):
__slots__ = (('name',))
def __init__(self, name):
self.name = name
green = Color('green') # Works
assert green.name == 'green'
Color.__new__ = 0
del Color.__new__
red = Color('red') # Fails in Python 3; works in Python 2 & pypy
assert red.name == 'red'
This works in Python 2, pypy, but fails in Python 3 as follows:
Traceback (most recent call last):
File "x.py", line 13, in
red = Color('red') # Fails in Python 3; works in Python 2 & pypy
TypeError: object() takes no parameters
--
messages: 328773
nosy: joydiamond
priority: normal
severity: normal
status: open
title: Deleting __new__ does not restore previous behavior
versions: Python 3.5, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35098>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35098] Deleting __new__ does not restore previous behavior
Joy Diamond added the comment:
Its quite valid to assign to __new__ to replace the behavior of how an instance
is created.
(Obviously you would not really assign `0` to it; my example was just to show
the `del Color.__new__` fails - so what was assigned was not relevant).
Here is a more realistic assignment to __new__ -- this one shows we are
"caching" the instance "green" -- so it is reused:
class Color(object):
__slots__ = (('name',))
def __init__(self, name):
self.name = name
green = Color('green') # Works
assert green.name == 'green'
@staticmethod
def Color__new__cache_green(m, name):
if name == 'green':
return green
return object.__new__(m, name)
Color.__new__ = Color__new__cache_green
green_2 = Color('green')
assert green_2 == green
blue = Color('blue')
assert blue.name == 'blue'
del Color.__new__
red = Color('red') # Fails in Python 3; works in Python 2 & pypy
assert red.name == 'red'
Finally as for `Color.__x__` assignment, this has nothing to do with
`__slots__` as it is assigning to `Color`, not to an instance of `Color`.
`green.__x__ = 0` properly fails since there is no `__x__` slot:
AttributeError: 'Color' object has no attribute '__x__'
--
___
Python tracker
<https://bugs.python.org/issue35098>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35106] Add documentation for `type.__subclasses__` to docs.python.org
New submission from Joy Diamond : Add documentation for `type.__subclasses__` to docs.python.org Python ideas discussion: https://mail.python.org/pipermail/python-ideas/2018-October/054361.html -- assignee: docs@python components: Documentation messages: 328848 nosy: docs@python, joydiamond priority: normal severity: normal status: open title: Add documentation for `type.__subclasses__` to docs.python.org versions: Python 2.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35106] Add documentation for `type.__subclasses__` to docs.python.org
Joy Diamond added the comment: Documented here: https://docs.python.org/3/library/stdtypes.html#class.__subclasses__ (Though does not appear in google searches) -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35158] Fix PEP 3115 to NOT imply that the class dictionary is used in the final created class
New submission from Joy Diamond : Fix the following in https://www.python.org/dev/peps/pep-3115/ REPLACE: """ def __new__(cls, name, bases, classdict): # Note that we replace the classdict with a regular # dict before passing it to the superclass, so that we # don't continue to record member names after the class # has been created. result = type.__new__(cls, name, bases, dict(classdict)) result.member_names = classdict.member_names return result """ WITH: """ def __new__(cls, name, bases, classdict): result = type.__new__(cls, name, bases, classdict) result.member_names = classdict.member_names return result """ REMOVING the incorrect comment & copying of `classdict` According to: https://docs.python.org/3/reference/datamodel.html#preparing-the-class-namespace "When a new class is created by type.__new__, the object provided as the namespace parameter is copied to a new ordered mapping and the original object is discarded." Hence there is no need to copy `classdict` -- messages: 329213 nosy: joydiamond priority: normal severity: normal status: open title: Fix PEP 3115 to NOT imply that the class dictionary is used in the final created class ___ Python tracker <https://bugs.python.org/issue35158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
