[issue45198] __set_name__ documentation not clear about its usage with non-descriptor classes
New submission from xitop :
The object.__set_name__() function (introduced in Python 3.6 by PEP-487) is
mentioned in the "what's new " summary as an extension to the descriptor
protocol [1] and documented in the "implementing descriptors" section [2].
However, the PEP itself states that it "adds an __set_name__ initializer for
class attributes, especially if they are descriptors.". And it indeed works for
plain classes where the descriptor protocol is not used at all (no __get__ or
__set__ or __delete__):
class NotDescriptor:
def __set_name__(self, owner, name):
print('__set_name__ called')
class SomeClass:
attr = NotDescriptor()
It is clear that this method is helpful when used in descriptors and that is
its intended use, but other valid use-cases probably exist.
I suggest to amend the documentation to clarify that (correct me if I'm wrong)
the __set_name__ is called for every class used as an attribute in an other
class, not only for descriptors.
---
URLs:
[1]:
https://docs.python.org/3/whatsnew/3.6.html#pep-487-descriptor-protocol-enhancements
[2]: https://docs.python.org/3/reference/datamodel.html#implementing-descriptors
--
assignee: docs@python
components: Documentation
messages: 401785
nosy: docs@python, xitop
priority: normal
severity: normal
status: open
title: __set_name__ documentation not clear about its usage with non-descriptor
classes
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue45198>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results
xitop added the comment: 2nd anniversary. Any reaction from developers would be appreciated. Thank you. -- ___ Python tracker <https://bugs.python.org/issue38085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results
xitop added the comment: Python 3.9.1 is affected too. -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue38085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results
xitop added the comment: Please, could some experienced Python developer take a look at this issue reported more than 3 month ago? -- ___ Python tracker <https://bugs.python.org/issue38085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results
xitop added the comment: Same problem also in Python 3.6.8 and the new 3.8.0. -- versions: +Python 3.6, Python 3.8 ___ Python tracker <https://bugs.python.org/issue38085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results
New submission from xitop :
An exception in __init__subclass__ leads under certain circumstances to wrong
isinstance() and issubclass() results. The exception probably leaves Python
internal data in inconsistent state.
Here is a demonstration program from Stack Overflow:
--- begin --
from abc import ABCMeta
class Animal(metaclass=ABCMeta):
pass
class Plant(metaclass=ABCMeta):
def __init_subclass__(cls):
assert not issubclass(cls, Animal), "Plants cannot be Animals"
class Dog(Animal):
pass
try:
class Triffid(Animal, Plant):
pass
except Exception:
pass
print("Dog is Animal?", issubclass(Dog, Animal))
print("Dog is Plant?", issubclass(Dog, Plant))
--- end --
Result is:
Dog is Animal? True
Dog is Plant? True
Changing the order of the print statements will result in:
Dog is Plant? False
Dog is Animal? False
Another ill-behaving program and a partial analysis can be found at SO:
https://stackoverflow.com/q/57848663/5378816
--
components: Interpreter Core
messages: 351599
nosy: xitop
priority: normal
severity: normal
status: open
title: Interrupting class creation in __init_subclass__ may lead to incorrect
isinstance() and issubclass() results
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue38085>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34993] asyncio.streams.FlowControlMixin should be part of the API
New submission from xitop : This issue report is based on a SO question "How to create asyncio stream reader/writer for stdin/stdout?", its answer and comments. Link: https://stackoverflow.com/q/52089869/5378816 The key point is that two unidirectional pipes should be used the same way as one bidirectional network socket. The answer (more precisely the Linux/Unix part of it) and some following comments - both created by highly competent SO members - suggest that FlowControlMixin is a useful class required to write a proper code for this and similar usecases. That's why the FlowControlMixin or an equivalent should be made available to asyncio programmers as a documented part of the library. -- components: asyncio messages: 327764 nosy: asvetlov, xitop, yselivanov priority: normal severity: normal status: open title: asyncio.streams.FlowControlMixin should be part of the API versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34993> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34748] Incorrect HTML link in functools.partial
New submission from xitop : There is a minor issue regarding the page https://docs.python.org/3/library/functools.html The description of functools.partial starts with text "Return a new partial object" which contains a link. This link does not point to the partial object (#partial-objects anchor) as it should. It points back to the partial function (#functools.partial anchor) which is not helpful. The partial object docs can be thus easily overseen. -- assignee: docs@python components: Documentation messages: 325856 nosy: docs@python, xitop priority: normal severity: normal status: open title: Incorrect HTML link in functools.partial versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32899] Not documented: key in dict test may raise TypeError
xitop added the comment: You are right. It is 'key in d', not 'object in d'. (Thanks for you patience. I'm sorry I did not get it right earlier.) -- ___ Python tracker <https://bugs.python.org/issue32899> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32899] Not documented: key in dict test may raise TypeError
xitop added the comment: While I do fully agree with not documenting all exceptions, I'd like to point out a major difference in the case of "unhashable in dict". It differs from the general case where an exception means the function is unable to return a meaningful result, beacuse it easily COULD return False as its documentation states. The exception is raised by a design decision, not by necessity. That makes it special. A single sentence like "A hashable key is precondition of all dict operations." would explain the behaviour well. That's all I wanted to say. Thank you. -- ___ Python tracker <https://bugs.python.org/issue32899> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32899] Not documented: key in dict test may raise TypeError
New submission from xitop : I'd like to suggest an addition to the documentation of the "key in dict" operation. Current version found at https://docs.python.org/3/library/stdtypes.html#dict says only: --- key in d Return True if d has a key key, else False. --- This is not precise. TypeError is also a possible outcome. It happens when the key is unhashable. Unsure whether the description is incomplete or the membership test has a bug I submitted the issue 32675 in January. The issue was closed with resolution of "not a bug". If it is indded the intended behaviour, I think it needs to be documented in order to prevent further misunderstandings. Before the issue 32675 I believed a membership test is failsafe, because the definition of __contains__ clearly defines the return value as either True or False. -- assignee: docs@python components: Documentation messages: 312506 nosy: docs@python, xitop priority: normal severity: normal status: open title: Not documented: key in dict test may raise TypeError type: enhancement ___ Python tracker <https://bugs.python.org/issue32899> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32675] dict.__contains__(unhashable) raises TypeError where False was expected
New submission from xitop :
The `dict.__contains()` function does not fully comply with the description in
the "Data Model" section of the official documentation, which states:
"__contains__(self, item) ... Should return true if item is in self, false
otherwise."
Basically the same is written in "Mapping Types - dict": "key in d - Return
True if d has a key key, else False."
According to that, testing a presence of an unhashable object in a dict should
return False. But it raises a TypeError instead.
Example:
>>> () in {}
False
but:
>>> [] in {}
Traceback (most recent call last):
File "", line 1, in
TypeError: unhashable type: 'list'
There is a related SO question:
https://stackoverflow.com/questions/48444079/unexpected-behaviour-of-dictionary-membership-check
currently without a clear answer whether it is a bug or desired behaviour
supposed to expose programming errors. In the latter case, it seems to be not
documented.
--
components: Interpreter Core
messages: 310751
nosy: xitop
priority: normal
severity: normal
status: open
title: dict.__contains__(unhashable) raises TypeError where False was expected
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue32675>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
