[issue43817] Add typing.get_annotations()

Change by Ken Jin : -- nosy: +kj ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43770] Rework C types initialization

STINNER Victor added the comment: If I modify type_ready() to call type_ready_inherit() before type_ready_fill_dict(), some types create a between between their C slot (tp_init) and the Python API in tp_dict (tp_dict["__init__"]). Example with importlib: class FileLoader(...): def

[issue43816] Missing 'extern "C"' for _Py_ctype_table

STINNER Victor added the comment: Stéphane Wirtel: "In fact, _Py_ctype_table is limited to the internal parts of the interpreter. So in this case, this one could not be used in an external tool. You can read: https://docs.python.org/3/c-api/stable.html; You're right that pyctype.h is

[issue43770] Rework C types initialization

STINNER Victor added the comment: New changeset a328d73843cfd42d2aee1434c78df1ef2845931a by Victor Stinner in branch 'master': bpo-43770: Cleanup type_ready() (GH-25388) https://github.com/python/cpython/commit/a328d73843cfd42d2aee1434c78df1ef2845931a --

[issue43830] (-1) ** 0.5 returns (6.123233995736766e-17+1j) instead of 1j

Change by Serhiy Storchaka : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue43830] (-1) ** 0.5 returns (6.123233995736766e-17+1j) instead of 1j

Serhiy Storchaka added the comment: It is the same "gotcha" as >>> math.cos(math.pi/2) 6.123233995736766e-17 You can expect that cos(π/2) is exactly 0, but floating point value math.pi is only an approximation of the π number. The difference between math.pi and exact value of π leads to

[issue43770] Rework C types initialization

Change by STINNER Victor : -- pull_requests: +24121 pull_request: https://github.com/python/cpython/pull/25388 ___ Python tracker ___

[issue43816] Missing 'extern "C"' for _Py_ctype_table

STINNER Victor added the comment: The workaround for this issue is to put extern "C" around #include , or around the header file which includes . -- ___ Python tracker ___

[issue43816] Missing 'extern "C"' for _Py_ctype_table

STINNER Victor added the comment: It's now fixed. Thanks Andrew V. Jones for the fix. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8 ___ Python tracker

[issue43816] Missing 'extern "C"' for _Py_ctype_table

STINNER Victor added the comment: New changeset 15ad30d88fead718b7eeff8c54454b82753d520e by Miss Islington (bot) in branch '3.9': bpo-43816: Add extern "C" to Include/cpython/pyctype.h (GH-25365) (GH-25387) https://github.com/python/cpython/commit/15ad30d88fead718b7eeff8c54454b82753d520e

[issue2824] zipfile to handle duplicate files in archive

Change by Felix C. Stegerman : -- nosy: +obfusk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43816] Missing 'extern "C"' for _Py_ctype_table

miss-islington added the comment: New changeset 47a894d338f436ea8f513f1ad2cc7e1b086e99cc by Miss Islington (bot) in branch '3.8': bpo-43816: Add extern "C" to Include/cpython/pyctype.h (GH-25365) https://github.com/python/cpython/commit/47a894d338f436ea8f513f1ad2cc7e1b086e99cc --

[issue40066] Enum: modify __repr__, __str__; update docs

Florian Bruhin added the comment: I'm probably a bit late to the party as well, but as some additional datapoints: - This broke the tests for my project and I ended up adding a wrapper to stringify enums (since I actually prefer having the enum type in debug logs and such):

[issue43770] Rework C types initialization

STINNER Victor added the comment: New changeset 65f058eb081c9e1fe44115d1ac7966067e3650c7 by Victor Stinner in branch 'master': bpo-43770: Reorder type_ready() (GH-25373) https://github.com/python/cpython/commit/65f058eb081c9e1fe44115d1ac7966067e3650c7 --

[issue43816] Missing 'extern "C"' for _Py_ctype_table

Change by miss-islington : -- pull_requests: +24120 pull_request: https://github.com/python/cpython/pull/25387 ___ Python tracker ___

[issue43816] Missing 'extern "C"' for _Py_ctype_table

Change by miss-islington : -- nosy: +miss-islington nosy_count: 5.0 -> 6.0 pull_requests: +24119 pull_request: https://github.com/python/cpython/pull/25386 ___ Python tracker

[issue43816] Missing 'extern "C"' for _Py_ctype_table

STINNER Victor added the comment: New changeset 54db51c9114ac49030832f5134979ca866ffd21c by Andrew V. Jones in branch 'master': bpo-43816: Add extern "C" to Include/cpython/pyctype.h (GH-25365) https://github.com/python/cpython/commit/54db51c9114ac49030832f5134979ca866ffd21c --

[issue43831] sqlite: convert_timestamp raises ValueError for empty columns

New submission from Lumír Balhar : Hello. I've discovered this issue when I was debugging a test failure in IPython. See this issue for more details (not needed): https://github.com/ipython/ipython/issues/12906 I'm testing this on Fedora Linux with Python 3.10.0a7 from our RPM package with

[issue43827] abc conflicts with __init_subclass__

Change by Vlad Hoi : -- keywords: +patch pull_requests: +24117 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25385 ___ Python tracker ___

[issue42722] Add --debug command line option to unittest to enable post-mortem debugging

Change by Rémi Lapeyre : -- nosy: +remi.lapeyre ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue14811] decoding_fgets() truncates long lines and fails with a SyntaxError("Non-UTF-8 code starting with...")

Change by Eryk Sun : -- versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker ___

[issue43731] PEP 597: logging.fileConfig() uses locale encoding.

Inada Naoki added the comment: If we use `encoding="locale"` by default, EncodingWarning will be not be emitted even when user omit `encoding` option. -- ___ Python tracker

[issue43760] The DISPATCH() macro is not as efficient as it could be.

Mark Shannon added the comment: New changeset 9e7b2076fb4380987ad0262c4c0ca900b06475ad by Mark Shannon in branch 'master': bpo-43760: Speed up check for tracing in interpreter dispatch (#25276) https://github.com/python/cpython/commit/9e7b2076fb4380987ad0262c4c0ca900b06475ad --

[issue43646] ForwardRef name conflict during evaluation

Ken Jin added the comment: @tefra, now that issue42904 has been solved, can you test your code again with 3.10.0a8? (it's not out yet, so you may have to pull the code from CPython's GitHub master branch and build CPython) Running your code again, it seems to be fixed: Python 3.10.0a7+ >>>

[issue43816] Missing 'extern "C"' for _Py_ctype_table

Stefan Behnel added the comment: The macros were moved to "Includes/cpython/", not to "Includes/internal/". That suggests to me that they should use "extern C", so that C++ code that wants to make use of CPython internals can use them. Basically, the way I see it, *all* header files in

[issue43830] (-1) ** 0.5 returns (6.123233995736766e-17+1j) instead of 1j

Steven D'Aprano added the comment: Sorry Nathan, I worded my first response awkwardly, of course mathematically we should expect a result of 1j, by why do you expect it in a floating point calculation? Do you have an alternative? (I promise this is my last comment until you have had a

[issue43830] (-1) ** 0.5 returns (6.123233995736766e-17+1j) instead of 1j

Steven D'Aprano added the comment: Before replying please read: https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate https://duckduckgo.com/?q=python+why+are+floating+point+so+inaccurate -- ___ Python

[issue43830] (-1) ** 0.5 returns (6.123233995736766e-17+1j) instead of 1j

Steven D'Aprano added the comment: What do you mean? It works as I expected. Can you explain what you expected, and why? -- nosy: +steven.daprano ___ Python tracker ___

[issue42904] get_type_hints does not provide localns for classes

Ken Jin added the comment: Yup I can! BTW, I agree with keeping the change in 3.10 only. I suspect it _may_ be backwards-incompatible in small edge cases (re: the long comment on the PR about suspicions with local and global scope). -- resolution: -> fixed stage: patch review ->

[issue43731] PEP 597: logging.fileConfig() uses locale encoding.

STINNER Victor added the comment: > fileConfig(fname, defaults=None, disable_existing_loggers=True, encoding=None) If "locale" is the intended default, why not being more explicit and use encoding="locale"? -- nosy: +vstinner ___ Python tracker

[issue38755] Long unicode string causes SyntaxError: Non-UTF-8 code starting with '\xe2' in file ..., but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

Change by Eryk Sun : -- stage: test needed -> needs patch versions: -Python 3.7 ___ Python tracker ___ ___ Python-bugs-list

[issue38755] Long unicode string causes SyntaxError: Non-UTF-8 code starting with '\xe2' in file ..., but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

Eryk Sun added the comment: > P.S. No problems with Python 3.8.5 and Ubuntu 20.04.2 LTS. The issue is that the line length is limited to BUFSIZ, which ends up splitting the UTF-8 sequence b'\xe2\x96\x91'. BUFSIZ is only 512 bytes in Windows. It's 8192 bytes in Linux, in which case you need

[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring

Shreyan Avigyan added the comment: PR opened for this issue. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring

Change by Shreyan Avigyan : -- keywords: +patch pull_requests: +24116 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25384 ___ Python tracker ___

[issue43731] PEP 597: logging.fileConfig() uses locale encoding.

Inada Naoki added the comment: New changeset c2b7a66b91cdb96fbfdb160f96797208ddc5e436 by Inada Naoki in branch 'master': bpo-43731: Add an `encoding` parameter to logging.fileConfig() (GH-25273) https://github.com/python/cpython/commit/c2b7a66b91cdb96fbfdb160f96797208ddc5e436 --

[issue43731] PEP 597: logging.fileConfig() uses locale encoding.

Change by Inada Naoki : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue43830] (-1) ** 0.5 returns (6.123233995736766e-17+1j) instead of 1j

Change by Christian Heimes : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue3451] Asymptotically faster divmod and str(long)

Carl Friedrich Bolz-Tereick added the comment: FWIW, we have implemented a faster algorithm for divmod for big numbers using Mark's fast_div.py in PyPy. In particular, this speeds up str(long) for large numbers significantly (eg calling str on the result of math.factorial(2**17) is now 15x

[issue43830] (-1) ** 0.5 returns (6.123233995736766e-17+1j) instead of 1j

New submission from Nathan Fallet : Complex exponentiation doesn't work as expected: ``` >>> (-1) ** 0.5 (6.123233995736766e-17+1j) ``` I think the issue is linked with this part of the code:

[issue43824] array.array.__deepcopy__() accepts a parameter of any type

Serhiy Storchaka added the comment: I you declare a method as METH_NOARGS, you would not able to pass any argument to it. I concur with Josh. There is nothing wrong here. -- nosy: +serhiy.storchaka resolution: -> not a bug stage: -> resolved status: open -> closed

[issue43824] array.array.__deepcopy__() accepts a parameter of any type

MingZhe Hu added the comment: copy.deepcopy() takes a memo argument for reason, but this memo object will not be used when passed to array.array.__deepcopy__(), that is, no matter called directly or not, as long as the C implementation of array.array.__deepcopy__() does not use the

[issue43829] MappingProxyType cannot hash a hashable underlying mapping

New submission from Andy Maier : Objects of MappingProxyType do expose a __hash__() method, but if the underlying mapping is hashable, it still does not support hashing it. Example: Content of mp_hash.py: -- #!/usr/bin/env python from nocasedict import NocaseDict, HashableMixin from

[issue43828] MappingProxyType accepts string

Change by Andy Maier : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43828] MappingProxyType accepts string

New submission from Andy Maier : MappingProxyType objects can currently be initialized from a string object. Given is purpose, I think this is a bug and should result in TypeError being raised. Example code (on CPython 3.9.1): >>> from types import MappingProxyType >>> mp =

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

Andrew Svetlov added the comment: Thanks for the reminder. You are correct, the mentioned PR should set _SSLProtocolTransport._start_tls_compatible to True -- ___ Python tracker

[issue43827] abc conflicts with __init_subclass__

New submission from Vlad Hoi : from abc import ABC class A: def __init_subclass__(self): pass class B(ABC, A, name="name"): pass After initialising class B, this exception occurs, because multiple "name" arguments where provided: Traceback (most recent call last): File

[issue43811] Run GHA CI with multiple OpenSSL versions

Christian Heimes added the comment: The new checks are only executed when one or more OpenSSL-related files are modified. The checks run a handful of networking and hashing test suites. All SSL checks are optional. This PR also introduces ccache to speed up compilation. In common cases it

[issue38755] Long unicode string causes SyntaxError: Non-UTF-8 code starting with '\xe2' in file ..., but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

Andrew Ushakov added the comment: Just tested again: D:\Downloads>py Python 3.9.4 (tags/v3.9.4:1f2e308, Apr 4 2021, 13:27:16) [MSC v.1928 64 bit

[issue43799] OpenSSL 3.0.0: define OPENSSL_API_COMPAT 1.1.1

Change by Christian Heimes : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue43799] OpenSSL 3.0.0: define OPENSSL_API_COMPAT 1.1.1

Christian Heimes added the comment: New changeset b71aaa0df0f3a9640b034b4774651cd8c54d2fb9 by Christian Heimes in branch '3.8': [3.8] bpo-43799: OpenSSL 3.0.0: declare OPENSSL_API_COMPAT 1.1.1 (GH-25329) (GH-25383)

[issue38820] Make Python compatible with OpenSSL 3.0.0

Change by Christian Heimes : -- dependencies: +OpenSSL 3.0.0: define OPENSSL_API_COMPAT 1.1.1, Run GHA CI with multiple OpenSSL versions ___ Python tracker ___

[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring

Shreyan Avigyan added the comment: Ok..then submitting the PR in 10 minutes. -- ___ Python tracker ___ ___ Python-bugs-list

[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring

Eryk Sun added the comment: > So are you telling that we should change the name to "ptr" to > avoid a breaking change? The function parameter name is "ptr". Changing that name could break existing code. I don't think it's likely, but it's not worth breaking even one script just for this.

[issue43799] OpenSSL 3.0.0: define OPENSSL_API_COMPAT 1.1.1

Change by Christian Heimes : -- pull_requests: +24115 pull_request: https://github.com/python/cpython/pull/25383 ___ Python tracker ___

[issue43799] OpenSSL 3.0.0: define OPENSSL_API_COMPAT 1.1.1

miss-islington added the comment: New changeset 7d9d5bf863bb0af26b74b0732ab89b2053d2fbec by Miss Islington (bot) in branch '3.9': [3.9] bpo-43799: OpenSSL 3.0.0: declare OPENSSL_API_COMPAT 1.1.1 (GH-25329) (GH-25382)

[issue43799] OpenSSL 3.0.0: define OPENSSL_API_COMPAT 1.1.1

Christian Heimes added the comment: New changeset a4833883c9b81b6b272cc7c5b67fa1658b65304c by Christian Heimes in branch 'master': bpo-43799: OpenSSL 3.0.0: declare OPENSSL_API_COMPAT 1.1.1 (GH-25329) https://github.com/python/cpython/commit/a4833883c9b81b6b272cc7c5b67fa1658b65304c

[issue43799] OpenSSL 3.0.0: define OPENSSL_API_COMPAT 1.1.1

Change by miss-islington : -- nosy: +miss-islington nosy_count: 1.0 -> 2.0 pull_requests: +24114 pull_request: https://github.com/python/cpython/pull/25382 ___ Python tracker

[issue43803] ctypes string_at/wstring_at - bad argument name used in docs and in docstring

Shreyan Avigyan added the comment: Ok...let me review again. Having different names for the same argument can cause confusion, right? So are you telling that we should change the name to "ptr" to avoid a breaking change? If this issue is confirmed, I'm ready to submit a PR to make this

<    1   2