[issue45847] Port module setup to PY_STDLIB_MOD() macro and addext()
Change by Oleg Iarygin : -- pull_requests: +30361 pull_request: https://github.com/python/cpython/pull/32299 ___ Python tracker <https://bugs.python.org/issue45847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45847] Port module setup to PY_STDLIB_MOD() macro and addext()
Change by Oleg Iarygin : -- pull_requests: -30358 ___ Python tracker <https://bugs.python.org/issue45847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45847] Port module setup to PY_STDLIB_MOD() macro and addext()
Change by Oleg Iarygin : -- nosy: +arhadthedev nosy_count: 5.0 -> 6.0 pull_requests: +30358 pull_request: https://github.com/python/cpython/pull/32299 ___ Python tracker <https://bugs.python.org/issue45847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45763] Detect compression libraries in configure
Change by Oleg Iarygin : -- nosy: +arhadthedev nosy_count: 1.0 -> 2.0 pull_requests: +30360 pull_request: https://github.com/python/cpython/pull/32299 ___ Python tracker <https://bugs.python.org/issue45763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45747] Detect dbm and gdbm dependencies in configure.ac
Change by Oleg Iarygin : -- nosy: +arhadthedev nosy_count: 4.0 -> 5.0 pull_requests: +30359 pull_request: https://github.com/python/cpython/pull/32299 ___ Python tracker <https://bugs.python.org/issue45747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47193] Use zlib-ng rather than zlib in binary releases
Change by Oleg Iarygin : -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue47193> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47168] Improvements for stable ABI definition files
Oleg Iarygin added the comment: Probably, `regen-limited-abi` needs to be called from `regen-all` so 'Check if generated files are up to date' CI job will become aware of it. -- ___ Python tracker <https://bugs.python.org/issue47168> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47168] Improvements for stable ABI definition files
Change by Oleg Iarygin : -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue47168> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47099] Replace with_traceback() with exception chaining and reraising
Change by Oleg Iarygin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47161] pathlib method relative_to doesnt work with // in paths
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +30271 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32193 ___ Python tracker <https://bugs.python.org/issue47161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47161] pathlib method relative_to doesnt work with // in paths
Oleg Iarygin added the comment: > But shouldn't it just work with `//` as a `/`? It seems like this is the > behavior elsewhere. It works elsewhere because empty directory names are impossible so can be dropped. But if `//` is placed in the beginning, it gets a special meaning that totally changes the whole path so its plain replacement would give a totally wrong one. Roughly speaking, "//Library/Video" is `/Video` on a computer named `Library`. -- ___ Python tracker <https://bugs.python.org/issue47161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47161] pathlib method relative_to doesnt work with // in paths
Oleg Iarygin added the comment: Also, the error message cannot be fixed because for 3.8 only security fixes are accepted since May 2021. For 3.9 and later, the message is already corrected. -- ___ Python tracker <https://bugs.python.org/issue47161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47161] pathlib method relative_to doesnt work with // in paths
Oleg Iarygin added the comment: As I found out, any path starting with two double slashes is treated as an UNC (network) path: root \\machine\mountpoint\directory\etc\... directory ^ So "/Library/Video" and "/" are directories mounted on your machine while "//Library/Video" is a computer named "Library" with a share named "Video". However, an error message in Python 3.8 (as a file path suggests) is misleading. In 3.11 it was changed to "'\\Library\Video\' is not in the subpath of '\' OR one path is relative and the other is absolute." -- ___ Python tracker <https://bugs.python.org/issue47161> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47161] pathlib method relative_to doesnt work with // in paths
Oleg Iarygin added the comment:
I started to investigate and found that a double slash in the beginning cancels
any parsing of a path:
>>> Path("//Library/Video")._parts
['Library\\Video\\']
vs
>>> Path("/Library/Video")._parts
['\\', 'Library', 'Video']
Investigating further.
--
nosy: +arhadthedev
___
Python tracker
<https://bugs.python.org/issue47161>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47128] Enhance Argument Clinic's NoneType return converter to give `void`
Oleg Iarygin added the comment: Actually, you're right. For now, PyErr_Occurred is a GIL lock plus a memory access. While the access is cheap because of a L1 cache hit, the GIL takes its toll in a hot path. So I'm closing the PR until GIL removal is done so no performance penalty will be imposed. I could use _PyErr_Occurred because "Currently Argument Clinic is considered internal-only for CPython", but it requires extra modifications of the clinic that is undesirable. -- ___ Python tracker <https://bugs.python.org/issue47128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47132] Move tests from setobject.c to _testcapimodule
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +30213 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32133 ___ Python tracker <https://bugs.python.org/issue47132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47132] Move tests from setobject.c to _testcapimodule
New submission from Oleg Iarygin : Currently, tests for PySet/PyFrozenSet C API are defined in Objects/setobject.c and available via set.test_c_api(). Moving them to, for example, _testcapimodule gives the following advantanges: - an internal, CPython-specific method stops being available in a public interface of the set class - CPython already has tests grouped into dedicated packages - the target package undefines NDEBUG thus making asserts available in release builds - a user may choose to omit the tests from a build not carrying them around - a file of 2.5k lines of codes becomes 152 lines smaller. -- components: C API, Tests messages: 416083 nosy: arhadthedev priority: normal severity: normal status: open title: Move tests from setobject.c to _testcapimodule type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47128] Enhance Argument Clinic's NoneType return converter to give `void`
Oleg Iarygin added the comment: > The function should return different values for success and error It does, and a `void` return type enforces it. Here is the trick: > An important convention throughout the Python interpreter is the following: > when a function fails, it should set an exception condition and return an > error value (usually -1 or a NULL pointer). > > - > https://docs.python.org/3/extending/extending.html#intermezzo-errors-and-exceptions Previously, a function could return NULL but forget to call `PyErr_*()`. With `void`, however, the function has no other choise but to properly set the error indicator so the Clinic's part will see it and return NULL finishing the convention. -- ___ Python tracker <https://bugs.python.org/issue47128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47128] Enhance Argument Clinic's NoneType return converter to give `void`
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +30205 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32126 ___ Python tracker <https://bugs.python.org/issue47128> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47128] Enhance Argument Clinic's NoneType return converter to give `void`
New submission from Oleg Iarygin :
The attached PR makes the following possible (note that the impl has a `void`
return type):
/*[clinic input]
_io._IOBase.writelines -> NoneType
lines: object
/
[clinic start generated code]*/
static void
_io__IOBase_writelines_impl(PyObject *self, PyObject *lines)
/*[clinic end generated code: output=f3feca36db72dbd1
input=286ba711cb7291ad]*/
Previously, the return type would be `Object *` with generated replacement of
non-Py_None values to NULL on the other side.
So now there is no need to track whether NULL or Py_None should be returned. Or
should it be Py_RETURN_NONE? Argument Clinic does it by itself returning NULL
on errors and PyNone otherwise:
static PyObject *
_io__IOBase_writelines(PyObject *self, PyObject *lines)
{
PyObject *return_value = NULL;
_io__IOBase_writelines_impl(self, lines);
if (PyErr_Occurred()) {
goto exit;
}
return_value = Py_None;
Py_INCREF(Py_None);
exit:
return return_value;
}
--
components: Argument Clinic
messages: 416062
nosy: arhadthedev, larry
priority: normal
severity: normal
status: open
title: Enhance Argument Clinic's NoneType return converter to give `void`
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue47128>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47109] Old ctypes.macholib tests are ignored by python -m test
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +30178 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32094 ___ Python tracker <https://bugs.python.org/issue47109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47109] Old ctypes.macholib tests are ignored by python -m test
New submission from Oleg Iarygin : Some tests for `ctypes.macholib.dyld` and all tests for `ctypes.macholib.dylib` and `ctypes.macholib.framework` are located outside of expected `ctypes.test` module and were not ported from `assert` to `unittest` facilities. This causes the following problems: - the tests aren't run by `python -m test` so they are effectively dead - an end user can run them by `python -m ctypes.macholib.dyld`, `python -m ctypes.macholib.dylib`, and `python -m ctypes.macholib.framework` - they are available even if a user chose to install CPython without tests -- components: Tests messages: 415935 nosy: arhadthedev priority: normal severity: normal status: open title: Old ctypes.macholib tests are ignored by python -m test type: behavior versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue47109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47099] Replace with_traceback() with exception chaining and reraising
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +30162 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32074 ___ Python tracker <https://bugs.python.org/issue47099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47099] Replace with_traceback() with exception chaining and reraising
New submission from Oleg Iarygin : Currently, exception chaining in Lib/ modules is implemented with pre-3.11 `raise Foo(...).with_traceback(sys.exc_info()[2])`. However, this approach can be simplified: 1. PEP 3134 introduced a proper `raise Foo(...) from bar` construction that takes a parent exception instead of its stack traceback 2. Without the traceback required, we partially get rid of `sys.exc_info` thus reducing active tapping into global internals A report printed into a console remains the same except a line: > During handling of the above exception, another exception occurred replaced with: > The above exception was the direct cause of the following exception -- components: Library (Lib) messages: 415864 nosy: arhadthedev priority: normal severity: normal status: open title: Replace with_traceback() with exception chaining and reraising type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47099> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47015] Update tests from asyncore to asyncio
Oleg Iarygin added the comment: The PR is ready for a review; I sorted out all bugs. -- ___ Python tracker <https://bugs.python.org/issue47015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47015] Update tests from asyncore to asyncio
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +29978 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31876 ___ Python tracker <https://bugs.python.org/issue47015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47015] Update tests from asyncore to asyncio
New submission from Oleg Iarygin : PEP 594 – Removing dead batteries from the standard library [1] removes asyncore and asynchat in 3.12 with the following note: > The asyncore module is also used in stdlib tests. The tests for ftplib, > logging, smptd, smtplib, and ssl are partly based on asyncore. These tests > must be updated to use asyncio or threading. (Note: the tests for `os` module are not mentioned and smtpd will be removed in 3.12 along with its tests anyway) I'm performing the update now to avoid keeping asynchat and asyncore as private subpackages of `test` package. [1] https://peps.python.org/pep-0594/ -- components: Tests messages: 415185 nosy: arhadthedev priority: normal severity: normal status: open title: Update tests from asyncore to asyncio type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46920] Remove code made dead long ago with #if 0
Change by Oleg Iarygin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46987] Remove _PySys_GetObjectId / _PySys_GetObjectId
Oleg Iarygin added the comment:
> ./top_5000/datatable-1.0.0.tar.gz: datatable-1.0.0/src/core/python/obj.cc:
> _PySys_GetObjectId(_stdin) // borrowed ref
All three occurences look like this [1] for two years (see git blame):
#ifndef Py_LIMITED_API
_PySys_GetObjectId(_stdin) // borrowed ref
#else
PySys_GetObject("stdin") // borrowed ref
#endif
So everything is fixed already.
[1]: https://github.com/h2oai/datatable/search?q=_PySys_GetObjectId
--
nosy: +arhadthedev
___
Python tracker
<https://bugs.python.org/issue46987>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46920] Remove code made dead long ago with #if 0
Change by Oleg Iarygin : -- pull_requests: +29912 pull_request: https://github.com/python/cpython/pull/31814 ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46920] Remove code made dead long ago with #if 0
Change by Oleg Iarygin : -- pull_requests: +29911 pull_request: https://github.com/python/cpython/pull/31813 ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46920] Remove code made dead long ago with #if 0
Change by Oleg Iarygin : -- pull_requests: +29910 pull_request: https://github.com/python/cpython/pull/31812 ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46920] Remove code made dead long ago with #if 0
Change by Oleg Iarygin : -- pull_requests: +29909 pull_request: https://github.com/python/cpython/pull/31811 ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46962] Fix docstrings that do not honor --without-doc-strings
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +29877 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31769 ___ Python tracker <https://bugs.python.org/issue46962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46962] Fix docstrings that do not honor --without-doc-strings
New submission from Oleg Iarygin : To support `--without-doc-strings`, all docstrings must be wrapped into `PyDoc_STRVAR` or `PyDoc_STR` (PEP 7). However, there are 18 occurrences in code and 10 in C API documentation that do not follow this rule. The documentation is important too because it should not teach people the wrong things. To find the occurrences I searched for `(?:^\s*.tp_doc = "|" \/\* tp_doc \*\/$)` and`^(?:static\s+)?const\s+char\s+[^=]+=\s*"`. -- assignee: docs@python components: Documentation, Extension Modules, Interpreter Core messages: 414768 nosy: arhadthedev, docs@python priority: normal severity: normal status: open title: Fix docstrings that do not honor --without-doc-strings type: behavior versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46946] Port core types to Argument Clinic
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +29841 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31725 ___ Python tracker <https://bugs.python.org/issue46946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46946] Port core types to Argument Clinic
New submission from Oleg Iarygin : This is done to: - update docstrings to current standards enforced by AC - get proper naming for arguments of impl-functions (for example, self instead of obj and instance) - strip boilerplate reducing current 16k lines of code to something little more manageable - get a proper excuse to collapse overbloated PyTypeObject initializers by throwing out zeroes with designated initialization thanks to C99&11 being promoted. For example, EncodingMapType in unicodeobject.c reduced from 43 lines to 8, five times less. -- components: Interpreter Core messages: 414670 nosy: arhadthedev priority: normal severity: normal status: open title: Port core types to Argument Clinic type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46942] Convert Object/classobject.c to Argument Clinic
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +29834 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31711 ___ Python tracker <https://bugs.python.org/issue46942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46942] Convert Object/classobject.c to Argument Clinic
New submission from Oleg Iarygin :
- Convert method.__reduce__, method.__new__, and instancemethod.__new__ to AC.
It looks like nothing else can be converted in classobject.c.
This is my first time working with AC so I could make some mistakes.
- Fix found mismatches in method.__new__ where docstring and implementation
diverged:
- on how to name arguments (function vs func, instance vs self) - `fuct` is a
semi-abbreviation and `self` is a special argument of instance methods. No
compatibility is harmed because these arguments were forced to be
positional-only anyway with `if (!_PyArg_NoKeywords("method", kw)) return
NULL;`.
- on whether args are positional (the implementation called
_PyArg_NoKeywords) or not (the documentation and
Lib/idlelib/idle_test/test_calltip.py:80) - align with other assertions in
`test_builtins()` that have reference docstrings with both `/` marker and a
proper description.
Minor refactoring:
- Since PyMethod_Type and PyInstanceMethod_Type are modified anyway, transform
their initialization to C99-style.
- Change a disabler for PyInstanceMethod_Type.tp_hash from comments to `#if 0`.
--
components: Interpreter Core
messages: 414643
nosy: arhadthedev
priority: normal
severity: normal
status: open
title: Convert Object/classobject.c to Argument Clinic
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue46942>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46920] Remove code made dead long ago with #if 0
Oleg Iarygin added the comment: I reverted my changes in Modules/_ctypes/libffi_osx/x86/x86-ffi64.c and Modules/_decimal/libmpdec/*step.c to not disturb third-party vendored libraries. As a result, macOS component is no longer affected along with the corresponding experts in a nosy list. -- components: -macOS nosy: -ned.deily, ronaldoussoren ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46920] Remove code made dead long ago with #if 0
Oleg Iarygin added the comment: Also forgot to add that git grep "#if 1" gives the following: - added on 20 Nov 2014 by d600951: cpython/Python/pylifecycle.c:2427. "/* Disable this if you have trouble debugging bootstrap stuff */" - after seven years, no trouble was found so this always-true guard has no use. -- ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46920] Remove code made dead long ago with #if 0
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +29800 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31681 ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46920] Remove code made dead long ago with #if 0
New submission from Oleg Iarygin : `git grep "#if 0"` gives the following occurences of dead code (analyzed with `git blame`, removed by a linked pull request): - added on 27 Apr 2020 by 2b74c83: Parser/pegen.h:9, Parser/pegen.h:15. Since these constants aren't mentioned anywhere else, I think it's some initial experiment now abandoned. - added on 23 Apr 2020 by c5fc156: Parser/pegen.c:40. `token_name` is mentioned nowhere in the CPython codebase too. - added on 20 Nov 2014 by d600951: Python/pylifecycle.c:1843 with the following note: > XXX This is disabled because it caused too many problems. If a __del__ or weakref callback triggers here, Python code has a hard time running, because even the sys module has been cleared out (sys.stdout is gone, sys.excepthook is gone, etc). One symptom is a sequence of information-free messages coming from threads (if a __del__ or callback is invoked, other threads can execute too, and any exception they encounter triggers a comedy of errors as subsystem after subsystem fails to find what it *expects* to find in sys to help report the exception and consequent unexpected failures). I've also seen segfaults then, after adding print statements to the Python code getting called. So the call is faulty for seven years with no progress. - added on 26 Oct 2013 by 8444ebb: Modules/sre_lib.h336. The Secret Labs' Regular Expression Engine was vendored nine years ago so `not used in this release` is permanent and can be removed. - added on 25 Aug 2012 by 2543756: Modules/_ctypes/libffi_osx/x86/x86-ffi64.c:155 - added on 21 Mar 2012 by 1919b7e: Modules/_decimal/libmpdec/sixstep.c:120, Modules/_decimal/libmpdec/sixstep.c:157, Modules/_decimal/libmpdec/fourstep.c:189, Modules/_decimal/libmpdec/fourstep.c:220 - added on 28 Sep 2011 by d63a3b8: Python/formatter_unicode.c:140. `DEBUG_PRINT_FORMAT_SPEC` is used nowhere, plus putting a debugger breakpoint onto an interesting `InternalFormatSpec` is more convenient. - added on 5 Mar 2008 by 7864476: Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c:40 - added on 27 Aug 2007 by e226b55: Objects/unicodeobject.c:13660, Objects/unicodeobject.c:14253. `_decimal2ascii` is mentioned nowhere else in the CPython codebase. - added on 11 Aug 2006 by 0e3f591: Python/compile.c:7873. Neither `dump_instr` nor `dump_basicblock` are used. - added on 7 Dec 2005 by 8c8836b: Modules/_elementtree.c:39. In addition, `ALLOC()` and `RELEASE()` are removed as unconditional no-ops. - added on 4 Aug 2002 by 00f1e3f: Parser/tokenizer.c:285. "/* Disable support for UTF-16 BOMs until a decision is made whether this needs to be supported */" - I have every reason to believe that the decision was Never Ever. - added on 23 Mar 2002 by c24ea08: Python/ceval.c:7065-L7070. The "/* future keyword */" is quite overdue already. - added on 23 Jun 2001 by 01dfdb3: Modules/getaddrinfo.c:41, Modules/getnameinfo.c:37 - added on 14 Jul 1998 by 43ff868: Modules/_tkinter.c:3443 -- components: Extension Modules, Interpreter Core, Unicode, macOS messages: 414519 nosy: arhadthedev, ezio.melotti, ned.deily, ronaldoussoren, vstinner priority: normal severity: normal status: open title: Remove code made dead long ago with #if 0 type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46920> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46816] Remove declarations for non-__STDC__ compilers
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +29596 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31466 ___ Python tracker <https://bugs.python.org/issue46816> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46816] Remove declarations for non-__STDC__ compilers
New submission from Oleg Iarygin : Currently, Python code contains two places where presence of __STDC__ is checked: - Include/internal/pycore_pymath.h:12 - Python/errors.c:13 These checks are used to add extern functions missing in non-standard versions of math.h. However, after Python switched to C99, there is a guarantee that every compiler conforms to ISO C so checks of __STDC__ have no sense anymore. Note, that: - errors.c check was added by 53e8d44 on 9 Mar 1995 - pycore_pymath.h check was initially added into Objects/floatobject.c by eddc144 on 20 Nov 2003 then moved to pycore_pymath by 53876d9. -- components: Interpreter Core messages: 413645 nosy: arhadthedev priority: normal severity: normal status: open title: Remove declarations for non-__STDC__ compilers type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46816> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46649] Propagate Python thread name to thread state structure
Oleg Iarygin added the comment: > bpo-15500 looks like a more generic option, debuggers should be able to > retrieve thread names. That option is not viable. 1. > Created on 2012-07-30 16:19 by bra, last changed 2022-01-19 00:32 by pitrou 2. > I don't think this should be done by default as it will break people's expectations and, perhaps worse, compatibility. 3. > It is indeed the compatibility that is the worse issue. The problem is what people have gotten used to and may have coded their applications to expect/deal with. I agree with you that most people would *not* find it surprising to see the name reflected in the OS, but I don't think the convenience of that is worth introducing a potential backward incompatibility. Any chances? -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue46649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41682] [Windows] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure
Change by Oleg Iarygin : -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue41682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45877] Inconsistency in minimal supported version of Microsoft Visual Studio
Change by Oleg Iarygin : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46038] Mark /configure file as generated in .gitattributes
Oleg Iarygin added the comment: Superseded by <https://github.com/python/core-workflow/issues/425>. The PR itself is included as a part of PR30745. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46038] Mark /configure file as generated in .gitattributes
Change by Oleg Iarygin : -- pull_requests: +28935 pull_request: https://github.com/python/cpython/pull/30745 ___ Python tracker <https://bugs.python.org/issue46038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34875] Change .js mime to "text/javascript"
Oleg Iarygin added the comment: Myles, it looks like the draft 14 contains a mismatch in 6.2.1: > # 6.2.1. text/ecmascript > > Type name: application > Subtype name: ecmascript In header it's `text`, in details it's `application`. Is it intended? I believe that a typo wouldn't pass though fourteen revisions but nevertheless, just to be safe. -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue34875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15500] Python should support exporting thread names to the OS
Oleg Iarygin added the comment: @r.david.murray > It is indeed the compatibility that is the worse issue. The problem is what > people have gotten used to and may have coded their applications to > expect/deal > with. I agree with you that most people would *not* find it surprising to see > the name reflected in the OS, but I don't think the convenience of that is > worth > introducing a potential backward incompatibility. For now, Python thread names are always empty (as in many other programs). So Python-oriented tools that could expect some other outcome to bother check the names are just impossible (there is no alternative semantics they could perform in non-empty case). -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue15500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46391] Library multiprocess leaks named resources.
Oleg Iarygin added the comment: I added core devs related to multiprocessing into a nosy list so they got a notification and the PR will be evaluated and merged faster. FYI, the devs are Davin Potts and Antoine Pitrou (as per <https://devguide.python.org/experts/>). -- nosy: +arhadthedev, davin, pitrou ___ Python tracker <https://bugs.python.org/issue46391> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46038] Mark /configure file as generated in .gitattributes
Change by Oleg Iarygin : -- keywords: +patch pull_requests: +28256 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30031 ___ Python tracker <https://bugs.python.org/issue46038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46038] Mark /configure file as generated in .gitattributes
New submission from Oleg Iarygin : configure is regenerated from configure.ac using a custom container with appropriate version of tools (quay.io/tiran/cpython_autoconf by Christian Heimes). As a result, configure falls into the same category as files generated by Argument Clinic, Freeze and Parser/asdl_c.py. Due to size and churn of these artifacts, they are marked in .gitattributes as generated so GitHub Pull Request Diff Viewer collapses them into a short notification. The pull request associated with this issue does the same for configure. Actually, configure diff is so large that sometimes it crosses a threshold and GitHub collapses it by force with "Large diffs are not rendered by default" or even "xxx additions, yyy deletions not shown because the diff is too large. Please use a local Git client to view these changes". See GH-29756 as an extreme example (15,430 insertions and deletions) and <https://github.com/python/cpython/commits/main/configure> for an average. -- components: Build messages: 408218 nosy: arhadthedev priority: normal severity: normal status: open title: Mark /configure file as generated in .gitattributes type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue46038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__
Oleg Iarygin added the comment: The reporter gave more details (<https://github.com/python/cpython/pull/11952#issuecomment-989430968>): > Literally this is ok in C++ with Qt: > > float x = 2.3, y = 1.1; > auto p = QPoint(x, y); // QPoint only takes 2 int params.. this works in > C++; floats can be always be implicitly converted to int > > Same code, more or less, in Python3.10 is now broken: > > x = 2.3 > y = 1.1 > p = QPoint(x, y) # This fails, where previously it worked on every > Python version since the age of the dinosaurs... > > Note that most of the API for PyQt5 is auto-generated from the function > signatures of the C++. So in this case QPoint takes 2 ints for its c'tor > (just like in C++).. and breaks on Python 3.10 if given floats, when > previously it worked just fine with either ints or floats. This is just 1 > example. But many codebases that use PyQt5 are hit by breakages like this one > now. -- ___ Python tracker <https://bugs.python.org/issue36048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36048] Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__
Oleg Iarygin added the comment: Here is a report that this change breaks PyQt5 on Fedora: <https://github.com/python/cpython/pull/11952#issuecomment-989298404> > [...] > > Why do I care? This breaks tons of existing PyQt5 code out there, for > example. I wasn't aware of this change to the language until Fedora shipped > Python 3.10 and everything broke. So much stuff that uses PyQt5 is broken > now. Good job guys!! > > [...] Even though the rest of comment is emotional, we need to check if the problem really has place and the PR needs to be retracted until PyQt5 is ported to newer Python C API. -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue36048> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45019] Freezing modules has manual steps but could be automated.
Oleg Iarygin added the comment: If a directory is renamed anyway, maybe `deepfrozen_modules` is better? `deepfreeze_modules` looks like "modules that are part of deepfreeze tool itself". Also it rhymes with `frozen_modules`. -- ___ Python tracker <https://bugs.python.org/issue45019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45019] Freezing modules has manual steps but could be automated.
Change by Oleg Iarygin : -- nosy: +arhadthedev nosy_count: 5.0 -> 6.0 pull_requests: +27981 pull_request: https://github.com/python/cpython/pull/29744 ___ Python tracker <https://bugs.python.org/issue45019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45883] reuse_address mistakenly removed from loop.create_server
Change by Oleg Iarygin : -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue45883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45869] Unicode and acii regular expressions do not agree on ascii space characters
Change by Oleg Iarygin : -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue45869> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37705] winerror_to_errno implementation
Change by Oleg Iarygin : -- nosy: +arhadthedev nosy_count: 7.0 -> 8.0 pull_requests: +27961 pull_request: https://github.com/python/cpython/pull/29724 ___ Python tracker <https://bugs.python.org/issue37705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45877] Inconsistency in minimal supported version of Microsoft Visual Studio
New submission from Oleg Iarygin : According to PCbuild/readme.txt: > Using this directory requires an installation of > Microsoft Visual Studio 2017 (MSVC 14.1) of any edition. However, Doc/using/windows.rst states that Visual Studio 2017 is not required and 2015 may be used instead: > The source tree contains a build solution and project files for Microsoft > Visual Studio 2015, which is the compiler used to build the official Python > releases. VS 2017 mention was introduced in GH-3418. So either PCbuild readme needs to relax its requirements back or windows.rst needs to be updated. -- assignee: docs@python components: Build, Documentation messages: 406826 nosy: arhadthedev, docs@python, steve.dower priority: normal severity: normal status: open title: Inconsistency in minimal supported version of Microsoft Visual Studio type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43827] abc conflicts with __init_subclass__
Oleg Iarygin added the comment: Paul, PR OP made all changes requested; could you re-review please? -- nosy: +arhadthedev, p-ganssle ___ Python tracker <https://bugs.python.org/issue43827> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45476] [C API] Disallow using PyFloat_AS_DOUBLE() as l-value
Oleg Iarygin added the comment:
Marc-Andre:
> Inlining is something that is completely under the control of the
used compilers. Compilers are free to not inline function marked for
inlining [...]
I checked the following C snippet on gcc.godbolt.org using GCC 4.1.2 and Clang
3.0.0 with /-O0/-O1/-Os, and both compilers inline a function marked
as static inline:
static inline int foo(int a)
{
return a * 2;
}
int bar(int a)
{
return foo(a) < 0;
}
So even with -O0, GCC from 2007 and Clang from 2011 perform inlining. Though,
old versions of CLang leave a dangling original copy of foo for some reason. I
hope a linker removes it later.
As for other compilers, I believe that if somebody specifies -O0, that person
has a sound reason to do so (like per-line debugging, building precise flame
graphs, or other specific scenario where execution performance does not
matter), so inlining interferes here anyway.
--
nosy: +arhadthedev
___
Python tracker
<https://bugs.python.org/issue45476>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45772] socket.socket should be a class instead of a function
Change by Oleg Iarygin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45772] socket.socket should be a class instead of a function
New submission from Oleg Iarygin : Found a twice stale bpo-less but useful pull request 23960, so publish it here: > Currently socket.socket is documented as a function, but it is really a class (and thus has function-like usage to construct an object). This correction would ensure that Python projects that are interlinking Python's documentation can properly locate socket.socket as a type. -- assignee: docs@python components: Documentation messages: 406045 nosy: arhadthedev, docs@python, xuhdev priority: normal pull_requests: 27751 severity: normal status: open title: socket.socket should be a class instead of a function versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45672] Mutation tests results of typing.py
Oleg Iarygin added the comment: > because this modification does not affect behavior Unfortunately, this one (that I missed by not reading the report thoroughly) makes the framework totally unsuitable for CI. However, looking at such false positives allows to muse about reasons behind design choises. For example (in a snippet you cited), why Python runtime stores bases as a tuple, not as a linked list. Anyway, application of the method resolution order scans them sequentially, they are not of a primitive type (so tuples give no optimization), a call of bases.index() may be replaced with a reference property inside class internals, etc. Though, I perfectly understand that such treatment leads to immense amount of refactoring with no performance gain, probably counterweighted with removal of couple of internal packages that will become unused after it. That's why I wrote about "a task of the OP themselves". -- ___ Python tracker <https://bugs.python.org/issue45672> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45672] Mutation tests results of typing.py
Oleg Iarygin added the comment: > What is the problem actually? I guess, Lib/test/test_typing.py has gaps in test coverage. The report provided by the OP is a list of random modifications that corrupt logic of Lib/typing.py but still pass all test cases. Mutation testing is validation of tests themselves. A mutation framework takes code that the validated test actually tests, makes some random but syntactically correct change, and runs the test that should fail some assertion here. If so, the code is rolled back and another mutation attempt is done. If the validated test catches all thousands of such attempts, we can consider it a reliable safety net for any refactoring. Otherwise, we open the report and start to supplement tests and probably package documentation to cover missed scenarios. Actually, something like cosmic-ray may be added into a CI pipeline, but I suspect that preliminary fixing of test coverage will be a task of the OP themselves. There are no people with enough free time to sit down and sort all tests out, being overwhelmed with new language features, bug fixing and already pending epics of, for example, closing Python internals from extension modules to stop constantly breaking backward compatibility, or fixing startup modules to properly freeze them for speedup of Python launching. -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue45672> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45702] Python/dtoa.c requires 53 bit hardware rounding unavalable on x64
Oleg Iarygin added the comment: When I first saw "default rounding precision of 64 bits", I've thought it's about "64 bit precision", aka binary64, aka double. So I suggested that the code expects some hardly known Intel FPU-specific binary56 instead. Now, after a second paragraph of your reply I see that in reality it's about significand precision (so rounding precision of 64 bits is for binary80, and 53 is for binary64). > at 53-bit precision (not 56-bit) You're right. That was a typo. Thank you for clarification, I'm closing the issue as not-a-bug. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45702] Python/dtoa.c requires 53 bit hardware rounding unavalable on x64
New submission from Oleg Iarygin : File configure.ac:4617 states the following: > # The short float repr introduced in Python 3.1 requires the > # correctly-rounded string <-> double conversion functions from > # Python/dtoa.c, which in turn require that the FPU uses 53-bit > # rounding; this is a problem on x86, where the x87 FPU has a default > # rounding precision of 64 bits. For gcc/x86, we can fix this by > # using inline assembler to get and set the x87 FPU control word. However, x64 programs use xmm0-7 SIMD registers instead of a FPU stack, so the requirement of hardware 56 bit rounding gets violated. _Py_SET_53BIT_PRECISION_* is unable to do anything here because SSE neither respects the FPU control word, nor provides its own. Considering that SSE is supported since Pentium III (1999), we can safely enforce its usage for x32 code via compiler flags as well, getting consistent behavior across builds. However, it requires revision of the requirement. We need to decide what to do with dtoa.c that supposedly relies on the requirement (providing short floats? It looks like _Py_dg_dtoa just stringifies as many digits as specified in ndigits argument. I didn't collect enough courage on this stage to analyze 484 uncommented lines (2370-2854) of bit manipulation over two-letter variables to find and fix the dependency). By the way, the only place that uses _Py_dg_dtoa is Objects/floatobject.c:949 doing it with an argument mode=3. I can resolve the issue, but I need some educated opinion on this 13-years old stuff (see git blame for configure.ac:4617) to not break things. Note: I initially added Mark Dickinson into the notifications as a person who created and maintained Python/dtoa.c until 2013. -- components: Interpreter Core messages: 405603 nosy: arhadthedev, mark.dickinson priority: normal severity: normal status: open title: Python/dtoa.c requires 53 bit hardware rounding unavalable on x64 type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45702> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45697] PyType_IsSubtype is doing excessive work in the common case
Oleg Iarygin added the comment: Dennis, can PyFrozenSet_Check and _PyObject_TypeCheck get rid of Py_IS_TYPE invocation then, so PyType_IsSubtype becomes the only source of truth here? -- nosy: +arhadthedev ___ Python tracker <https://bugs.python.org/issue45697> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
