[issue44703] deepcopy(frozenset()) returns a new object
Change by Svyatoslav : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue44703> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44704] frozenset.__hash__ vs. Set._hash
New submission from Svyatoslav :
In docstring of Set._hash in _collections_abc.py is written:
"We match the algorithm used by the built-in frozenset type."
But
>>> s = frozenset({i for i in range(10)})
>>> hash(s)
3895031357313128696
>>> Set._hash(s)
3914343279946282847
Looks like Set._hash is different.
--
components: Library (Lib)
messages: 397963
nosy: Prometheus3375
priority: normal
severity: normal
status: open
title: frozenset.__hash__ vs. Set._hash
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44704>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44703] deepcopy(frozenset()) returns a new object
New submission from Svyatoslav :
from copy import copy, deepcopy
t = 1, 2
t1 = t, 3
t2 = t1, 4
t3 = t2, 5
assert copy(t3) is t3
assert deepcopy(t3) is t3
s = frozenset({1, 2})
assert s.copy() is s # method .copy() always returns self, what its purpose?
assert copy(s) is s
assert deepcopy(s) is s # raises AssertionError
Even a deepcopy of a tuple with many nested tuples is the the tuple itself,
while a deepcopy of a frozenset which by definition cannot contain mutable
objects is a new frozenset.
I think it is an error. A new frozenset is created because deepcopy() fallbacks
to pickling.
--
components: Library (Lib)
messages: 397961
nosy: Prometheus3375
priority: normal
severity: normal
status: open
title: deepcopy(frozenset()) returns a new object
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue44703>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44702] Fix weakref doc
New submission from Svyatoslav : >From https://docs.python.org/3/library/weakref.html: "" Not all objects can be weakly referenced; those objects which can include class instances, functions written in Python (but not in C), instance methods, sets, frozensets, some file objects, generators, type objects, sockets, arrays, deques, regular expression pattern objects, and code objects. "" My first perception was that this is the list of objects without weakref support. Actually, the sentence lists objects which do support weakref. While writing this report I understood: "can" does not relate to "include" at all. The correct way of reading is "those objects | which can | include ...". Previously I had read it as "those objects | which can include ...". Even Google translates in such manner, commas do not help. To remove ambguity, I suggest such fix: "" Not all objects can be weakly referenced. Objects which support weak references include class instances, functions written in Python (but not in C), instance methods, sets, frozensets, some file objects, generators, type objects, sockets, arrays, deques, regular expression pattern objects, and code objects. "" or "" Not all objects can be weakly referenced. Сlass instances, functions written in Python (but not in C), instance methods, sets, frozensets, some file objects, generators, type objects, sockets, arrays, deques, regular expression pattern objects, and code objects support weak references. "" -- assignee: docs@python components: Documentation messages: 397960 nosy: Prometheus3375, docs@python priority: normal severity: normal status: open title: Fix weakref doc type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43261] Python 3.9 repair on Windows do not recover pip module
Svyatoslav added the comment: Attached logs created right before I created this post. -- Added file: https://bugs.python.org/file49829/Temp.zip ___ Python tracker <https://bugs.python.org/issue43261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43261] Python 3.9 repair on Windows do not recover pip module
New submission from Svyatoslav : I by mistake run command `pip install -U pip setuptools wheel` on Windows which deleted pip and did not install a new version. I decided to repair Python using 3.9.1 installer option. But after repair pip still was not installed. -- components: Windows messages: 387285 nosy: Prometheus3375, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Python 3.9 repair on Windows do not recover pip module type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43261> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42829] get_type_hints throws for nested class with __future__ annotations
Svyatoslav added the comment: > This is because get_type_hints looks only at mro of the class. Its namespace must be included too as locals < I'll correct myself. get_type_hints() looks at all entites of mro of a class. If globals are not defined, globals of an entity module are used. But if locals are not defined, then no action is taken. Actually, class namespace must be used as locals in that case. This is also supported by the case when a class and its module have classes with the same name. See same_classes.py for an example. -- Added file: https://bugs.python.org/file49720/same_classes.py ___ Python tracker <https://bugs.python.org/issue42829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42829] get_type_hints throws for nested class with __future__ annotations
New submission from Svyatoslav : If a class X has nested class Y and class X has annotation Y AFTER the definition of Y, get_type_hints(X) throws NameError if import from future annotations is present. This is because get_type_hints looks only at mro of the class. Its namespace must be included too as locals. -- files: annotations.py messages: 384381 nosy: Prometheus3375 priority: normal severity: normal status: open title: get_type_hints throws for nested class with __future__ annotations versions: Python 3.9 Added file: https://bugs.python.org/file49719/annotations.py ___ Python tracker <https://bugs.python.org/issue42829> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42786] Different repr for collections.abc.Callable and typing.Callable
Svyatoslav added the comment: Thanks a lot! I am closing this issue. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42786] Different repr for collections.abc.Callable and typing.Callable
Svyatoslav added the comment: Ok, thanks for the answer. Did I understand correctly that the issue will be fixed in 3.9.2 as well? -- ___ Python tracker <https://bugs.python.org/issue42786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42786] Different repr for collections.abc.Callable and typing.Callable
New submission from Svyatoslav :
Was making some typing conversions to string and noticed a different behavior
of collections.abc.Callable and typing.Callable here in 3.9.1. Issues
issue42195 and issue40494 can be related.
>>> import collections, typing
>>> repr(collections.abc.Callable[[int], str])
"collections.abc.Callable[[], str]"
>>> repr(typing.Callable[[int], str])
'typing.Callable[[int], str]'
The variant from collections is wrong, it is not consistent with other
GenericAlias reprs like
>>> repr(tuple[list[float], int, str])
'tuple[list[float], int, str]'
The problem is actually in the list usage to denote callable arguments:
>>> repr(tuple[[float], int, str])
"tuple[[], int, str]"
Here is the same error. This error disallows to use typing in eval/exec
statements:
>>> c = collections.abc.Callable[[int], str]
>>> d = eval(repr(c))
Traceback (most recent call last):
File "", line 1, in
File "", line 1
collections.abc.Callable[[], str]
^
SyntaxError: invalid syntax
Ofc there is no such problem with typing.Callable:
>>> c = typing.Callable[[int], str]
>>> d = eval(repr(c))
>>>
Interesting, if pass a list into typing.Tuple, an exception is raised:
>>> repr(typing.Tuple[[float], int, str])
Traceback (most recent call last):
File "", line 1, in
File "f:\software\python3.9\lib\typing.py", line 262, in inner
return func(*args, **kwds)
File "f:\software\python3.9\lib\typing.py", line 896, in __getitem__
params = tuple(_type_check(p, msg) for p in params)
File "f:\software\python3.9\lib\typing.py", line 896, in
params = tuple(_type_check(p, msg) for p in params)
File "f:\software\python3.9\lib\typing.py", line 151, in _type_check
raise TypeError(f"{msg} Got {arg!r:.100}.")
TypeError: Tuple[t0, t1, ...]: each t must be a type. Got [].
I think it is not correct that tuple accepts lists as generics, i. e. for
tuple[[float], int, str] an exception as above should be raised. Bu this is the
topic for other issue (maybe even already reported).
--
messages: 384068
nosy: Prometheus3375
priority: normal
severity: normal
status: open
title: Different repr for collections.abc.Callable and typing.Callable
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42786>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33771] Module: timeit. According to documentation default_repeat should have the value 3. Has 5.
Change by Svyatoslav : -- assignee: -> docs@python components: +Documentation nosy: +docs@python ___ Python tracker <https://bugs.python.org/issue33771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33771] Module: timeit. According to documentation default_repeat should have the value 3. Has 5.
Change by Svyatoslav : -- components: Library (Lib) nosy: svyatoslav priority: normal severity: normal status: open title: Module: timeit. According to documentation default_repeat should have the value 3. Has 5. type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
