[issue42111] Make the xxlimited module an example of best extension module practices
New submission from Petr Viktorin : The "xxlimited" module (Modules/xxlimited.c) was added as part of PEP 384 (Defining a Stable ABI), and is undocumented. As far as I can tell, it was added partly to test the stable ABI, and partly as an example of how to write a module (like "xx" from xxmodule.c). In the last few years the module has not seen much maintenance, and I believe it's no longer a good example to follow: it works, but there are now better ways to do things. I would like to take over maintenance of the module and make it into an example of how to write a low-level C extension with isolated module state, as described in PEP 630 (Isolating Extension Modules) -- an informational PEP that I plan to convert to a HOWTO doc when everything is ready. The old module will be kept around to test the 3.5 stable ABI. Past discussion: https://mail.python.org/archives/list/python-...@python.org/thread/FO3YPG3YLG2XF5FKHICJHNINSPY4OHEL/#YITRQXGUOIEHK22QP5K4C5E45QA356U3 -- components: C API messages: 379241 nosy: petr.viktorin priority: normal severity: normal status: open title: Make the xxlimited module an example of best extension module practices versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40891] Use PEP 573 in functools
Petr Viktorin added the comment: Here is a PR for _PyType_GetModuleByDef: https://github.com/python/cpython/pull/22835 -- ___ Python tracker <https://bugs.python.org/issue40891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Change by Petr Viktorin : -- nosy: +petr.viktorin nosy_count: 18.0 -> 19.0 pull_requests: +21792 pull_request: https://github.com/python/cpython/pull/22838 ___ Python tracker <https://bugs.python.org/issue1635741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42100] Add _PyType_GetModuleByDef
Change by Petr Viktorin : -- keywords: +patch pull_requests: +21789 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22835 ___ Python tracker <https://bugs.python.org/issue42100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42100] Add _PyType_GetModuleByDef
Change by Petr Viktorin : -- components: +C API type: -> enhancement versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue42100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42100] Add _PyType_GetModuleByDef
New submission from Petr Viktorin : I would like to add an internal _PyType_GetModuleByDef function to unblock further work on isolating extension modules, as discussed here: https://mail.python.org/archives/list/capi-...@python.org/thread/T3P2QNLNLBRFHWSKYSTPMVEIL2EEKFJU/ -- messages: 379163 nosy: petr.viktorin priority: normal severity: normal status: open title: Add _PyType_GetModuleByDef ___ Python tracker <https://bugs.python.org/issue42100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41726] Update refcounts info of PyType_FromModuleAndSpec in refcounts.dat
Petr Viktorin added the comment: New changeset 38a17d0752781c70fd971f372ddc8d3caf5ded88 by Miss Skeleton (bot) in branch '3.9': bpo-41726: Update the refcounts info of PyType_FromModuleAndSpec in refcounts.dat (GH-22112) (GH-22808) https://github.com/python/cpython/commit/38a17d0752781c70fd971f372ddc8d3caf5ded88 -- ___ Python tracker <https://bugs.python.org/issue41726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41726] Update refcounts info of PyType_FromModuleAndSpec in refcounts.dat
Change by Petr Viktorin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40703] PyType_FromSpec*() overwrites the type's "__module__"
Change by Petr Viktorin : -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue40703> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40703] PyType_FromSpec*() overwrites the type's "__module__"
Petr Viktorin added the comment: Thank you, Stefan! This should have a test as well. I'm willing to mentor someone who wants to get into the C-API, otherwise this has low priority for me. -- resolution: -> fixed stage: test needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40703> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41618] [C API] How many slots of static types should be exposed in PyType_GetSlot()
Petr Viktorin added the comment: Also: PyType_GetSlot should return a function pointer, not data. For some slots (Py_tp_doc, Py_tp_methods, Py_tp_members, Py_tp_getset) that ship has sailed, but for new ones, we should honor the distinction between data and function pointers. The C standard says they're distinct, so it might bite us in the future (e.g. compiling to WebAssembly). -- ___ Python tracker <https://bugs.python.org/issue41618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42035] [C API] PyType_GetSlot cannot get tp_name
Petr Viktorin added the comment: Ah, scratch that: PyType_GetSlot returns a function pointer. To be correct, we should to expose a new function like PyType_GetName. It's true that CPython currently doesn't always honor the distinction between data and function pointers, but the C standard says they're distinct, so it might bite us in the future. -- ___ Python tracker <https://bugs.python.org/issue42035> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38787] PEP 573: Module State Access from C Extension Methods
Petr Viktorin added the comment: Thanks Victor, Hai Shi, Pablo, Stefan, Dong-hee Na and Mariatta for reviews! I did not put all the details in the documentation because there are still feature gaps. So, a full write-up is now in the informational PEP 630. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41798] [C API] Revisit usage of the PyCapsule C API with multi-phase initialization API
Petr Viktorin added the comment: Also note that the capsule generally needs to hold references to the objects in exposes, and not rely on the module object to keep things alive. (Module objects with multi-phase init are not unique nor immortal.) _ctypes is an exception, since it doesn't have ant PyObject*. But in most others the destructor should also contain some DECREFs. -- ___ Python tracker <https://bugs.python.org/issue41798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41726] Update refcounts info of PyType_FromModuleAndSpec in refcounts.dat
Petr Viktorin added the comment: Definitely. Sorry for the delay -- I missed the notification here. -- ___ Python tracker <https://bugs.python.org/issue41726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42035] [C API] PyType_GetSlot cannot get tp_name
Petr Viktorin added the comment: The slots are originally intended for defining types (PyType_FromSpec); PyType_GetSlot is not as useful as it could be. tp_name can be exposed, but it needs to also be handled properly PyType_FromSpec -- e.g. raise an error. -- ___ Python tracker <https://bugs.python.org/issue42035> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41798] [C API] Revisit usage of the PyCapsule C API with multi-phase initialization API
Change by Petr Viktorin : -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue41798> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41797] PyModule_GetState doesn't work with LazyLoader
New submission from Petr Viktorin : One underlying issue from bpo-41631 is that importlib.util.LazyLoader produces modules that are only fully loaded after an attribute is accessed (through __getattribute__). C-API functions like PyModule_GetState, PyModule_GetDict and such do not get attributes, and when called on a _LazyModule, they might try to access uninitialized C-level state. I see two possible ways to fix this: - Make PyModule_GetState, etc. trigger a full load. Since this is C-API, it would need a fast (no Python code) way either to do the full load or to detect _LazyModule. - Make LazyLoader eager for either all extension & builtin modules, or for modules that have C-level storage. The latter would need a way to pass info from PyModuleDef to the loader. Brett, does that analysis make sense from the importlib POV? -- components: C API messages: 376991 nosy: brett.cannon, petr.viktorin priority: normal severity: normal status: open title: PyModule_GetState doesn't work with LazyLoader ___ Python tracker <https://bugs.python.org/issue41797> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41796] _ast module state should be made per interpreter
Petr Viktorin added the comment: I started this here: https://github.com/python/cpython/commit/60960cba606573450e76934c954787419524147d Feel free to take that code. -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue41796> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41726] Update refcounts info of PyType_FromModuleAndSpec in refcounts.dat
Petr Viktorin added the comment: New changeset 1e2f051a6127904cfee5f9e4021dd6e4a4d51c0f by Hai Shi in branch 'master': bpo-41726: Update the refcounts info of PyType_FromModuleAndSpec in refcounts.dat (GH-22112) https://github.com/python/cpython/commit/1e2f051a6127904cfee5f9e4021dd6e4a4d51c0f -- ___ Python tracker <https://bugs.python.org/issue41726> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41631] _ast module: get_global_ast_state() doesn't work with Mercurial lazy import
Petr Viktorin added the comment: That is interesting. The original post here doesn't mention that the problem occurs in Mercurial's "make all", specifically when building documentation, in the command: /usr/bin/python3.9 gendoc.py "hgrc.5" > hgrc.5.txt.tmp Could you confirm `make all` works OK with python3.9 on Arch? -- ___ Python tracker <https://bugs.python.org/issue41631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41618] [C API] How many slots of static types should be exposed in PyType_GetSlot()
Petr Viktorin added the comment: IMO, a slot should be exposed if there is some reason for exposing it. bpo-41073 talks about tp_dealloc, which is already exposed as Py_tp_dealloc. Recently, Py_bf_* slots were exposed (but not as part of the limited API), in bpo-40724 which links to the reasons for exposing them. Which other slots are we missing? -- ___ Python tracker <https://bugs.python.org/issue41618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41631] _ast module: get_global_ast_state() doesn't work with Mercurial lazy import
Petr Viktorin added the comment: We need this bug solved for 3.9.0 rc2. Łukasz, you're the one to make the call about the approach; how can we make your job easier? My view is: - Victor's PR 21961 is going in the right direction. But, as far as I know (correct me if I'm wrong), Victor unfortunately has less time for CPython than usual, for personal reasons. So, the PR is unexpectedly stalled. I don't think there's enough time to fix and test it for RC 2. - My PR 21973 essentially just provides a better error message (and might prevent segfaults in more convoluted cases -- essentially ones where the _ast module is replaced maliciously). We can merge it, backport to 3.9; then iterate on Victor's PR to have a better solution in 3.10. But Pablo an Victor should chime in as well. -- ___ Python tracker <https://bugs.python.org/issue41631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41631] _ast module: get_global_ast_state() doesn't work with Mercurial lazy import
Petr Viktorin added the comment: I also looked into Mercurial. They have a large list of modules [0] that don't work with the lazy-loading scheme. I don't think adding one more should be a big problem for them; but we'll reach out to them and confirm that. [0] https://www.mercurial-scm.org/repo/hg/file/tip/hgdemandimport/__init__.py#l26 -- ___ Python tracker <https://bugs.python.org/issue41631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38787] PEP 573: Module State Access from C Extension Methods
Petr Viktorin added the comment: New changeset d9a966ae08258da2ce2a432c943d8194760f09c4 by Petr Viktorin in branch 'master': bpo-38787: Clarify docs for PyType_GetModule and warn against common mistake (GH-20215) https://github.com/python/cpython/commit/d9a966ae08258da2ce2a432c943d8194760f09c4 -- ___ Python tracker <https://bugs.python.org/issue38787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41631] _ast module: get_global_ast_state() doesn't work with Mercurial lazy import
Change by Petr Viktorin : -- pull_requests: +21082 pull_request: https://github.com/python/cpython/pull/21973 ___ Python tracker <https://bugs.python.org/issue41631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41631] _ast module: get_global_ast_state() doesn't work with Mercurial lazy import
Petr Viktorin added the comment: > Also, option 1 is virtually equivalent to the state of the _ast module prior > to the recent changes except that the symbols are in a shared object instead > of the binary or libpython. The advantage here is not moving them out of the > shared object, is making them having static storage. What I'm not yet clear on: when is that shared object is initialized and destroyed? > Would that impact performance considerably? > Also, adding them into a module that needs access through Python had a > bootstrap problem Only for PyCF_ONLY_AST, which is, AFAIK, not used by the interpreter itself. -- ___ Python tracker <https://bugs.python.org/issue41631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41631] _ast module: get_global_ast_state() doesn't work with Mercurial lazy import
Petr Viktorin added the comment: Regarding ac46eb4ad6662cf6d771b20d8963658b2186c48c: Module states come and go with the modules that contain them; if a "get_global_ast_state" or "astmodulestate_global" needs to be accessed from outside the module, it shouldn't be module state :/ So, the main issue here is that the AST types are not used only by the _ast module, but by the interpreter itself: the compile() builtin and Py_CompileStringObject. I see two ways of fixing this properly: 1. All the classes _ast provides should be built-in, like, say, `function`. (Currently, that means they should be static types; later they could be per-interpreter.) The _ast module should merely expose them from Python, like the `types` module exposes the function type. This would mean that calling Py_CompileStringObject with PyCF_ONLY_AST will be independent of the _ast module. 2. The mod2obj/obj2mod functions, called by e.g. compile(..., PyCF_ONLY_AST), should: * import the _ast module * call a Python-accessible function, e.g. _ast._mod2obj This would mean replacing the _ast module (in sys.modules or through an import hook, which you can do from Python code) will affect what AST types will be used throughout the interpreter. -- nosy: +dino.viehland, eric.snow, petr.viktorin ___ Python tracker <https://bugs.python.org/issue41631> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41168] Lack of proper checking in PyObject_SetAttr leads to segmentation fault
Petr Viktorin added the comment: Closing; please re-open if you have more info. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue41168> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39017] Infinite loop in the tarfile module
Change by Petr Viktorin : -- pull_requests: +20632 pull_request: https://github.com/python/cpython/pull/21489 ___ Python tracker <https://bugs.python.org/issue39017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39017] Infinite loop in the tarfile module
Petr Viktorin added the comment: Larry and Ned, do you want this fix in the security-only releases you manage? PRs for 3.6 ad 3.7 are ready, should you wish to merge them. -- nosy: +larry, ned.deily -miss-islington ___ Python tracker <https://bugs.python.org/issue39017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39017] Infinite loop in the tarfile module
Petr Viktorin added the comment: New changeset 5a8d121a1f3ef5ad7c105ee378cc79a3eac0c7d4 by Rishi in branch 'master': bpo-39017: Avoid infinite loop in the tarfile module (GH-21454) https://github.com/python/cpython/commit/5a8d121a1f3ef5ad7c105ee378cc79a3eac0c7d4 -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue39017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41191] PyType_FromModuleAndSpec is not mentioned in 3.9 What's new
Change by Petr Viktorin : -- keywords: +patch pull_requests: +20518 stage: -> patch review pull_request: https://github.com/python/cpython/pull/21374 ___ Python tracker <https://bugs.python.org/issue41191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41043] Escape the literal part of the path for glob()
Petr Viktorin added the comment: Would it be worth it to add a "base" keyword argument to glob.glob? -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue41043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41168] Lack of proper checking in PyObject_SetAttr leads to segmentation fault
Petr Viktorin added the comment: What kind of security-related issues do you mean? A .pyc file is code; it can do anything. Never run untrusted code, be it .py or .pyc. See also: Lib/test/crashers/bogus_code_obj.py -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue41168> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41073] [C API] PyType_GetSlot() should accept static types
Petr Viktorin added the comment: > If we extend PyType_GetSlot() to accept non-heaptype, we need find a way to > judge the max slot of non-heaptype. Static types can have some sub-slots structs but not others. A "max slot" will not help for types that have tp_as_mapping but not tp_as_number, for example. You'll probably need some table like typeslots.inc to record which sub-slots struct each slot belongs to. -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue41073> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40971] Documentation still mentions 'u' string formatting option
Petr Viktorin added the comment: I'm closing the issue. Please comment or reopen if I missed something. -- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40971] Documentation still mentions 'u' string formatting option
Petr Viktorin added the comment: AFAICS, Python 3 suports '%u' for printf-style formatting: Python 3.8.3 (default, May 29 2020, 00:00:00) [GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> '%u' % 6 '6' What am I missing? -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue40971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39960] Using typename.__setattr__ in extension type with Py_TPFLAGS_HEAPTYPE is broken (hackcheck too eager?)
Petr Viktorin added the comment: > do we still only support single inheritance at the C level? Not any more. Heap types may have multiple bases, and they can be created at the C level (since Python 3.2, PEP 384). > So, I think we should do something like walking up the hierarchy to find the > C function in it that is currently being called, and then check if it's the > one we would expect or if a subclass defines a different one. The current > check does not bother to search and just assumes that it knows which > (super)type defines the right function to call. Should we be bold and skip the check for heap types? That would mean that when/if `str` is converted to a heap type, you could do `object.__delattr__(str, "lower")`. That would break your Python, but only at the Python level (similar to things like `import builtins; del builtins.__build_class__`). Heap types are not shared between interpreters, so that reason is gone. But Guido's [2003 mail] suggests there are other reasons to prevent changing built-in types. What are they? [2003 mail] https://mail.python.org/pipermail/python-dev/2003-April/034535.html -- ___ Python tracker <https://bugs.python.org/issue39960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40891] Use pep573 in functools
Petr Viktorin added the comment: I wrote about the _PyType_GetModuleByDef idea on the capi-sig mailing list: https://mail.python.org/archives/list/capi-...@python.org/thread/T3P2QNLNLBRFHWSKYSTPMVEIL2EEKFJU/ -- ___ Python tracker <https://bugs.python.org/issue40891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39372] The header files in Include/ have many declarations with no definition
Petr Viktorin added the comment: Since the removal of PyNoArgsFunction breaks user code, does it deserve a mention in What's New – Porting to Python 3.9? -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue39372> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15577] Real argc and argv in embedded interpreter
Petr Viktorin added the comment: FWIW, another project that needs Py_GetArgcArgv is "setproctitle": https://bugzilla.redhat.com/show_bug.cgi?id=1792059 See also: https://github.com/cherrypy/cherrypy/issues/1506 -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue15577> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type
Change by Petr Viktorin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40777] _datetimemodule.c:3328:16: error: initializer element is not constant
Change by Petr Viktorin : -- keywords: +patch nosy: +petr.viktorin nosy_count: 1.0 -> 2.0 pull_requests: +19742 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20493 ___ Python tracker <https://bugs.python.org/issue40777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24416] Have date.isocalendar() return a structseq instance
Petr Viktorin added the comment: This broke compilation with mingw; see https://bugs.python.org/issue40777 -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue24416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40724] Support buffer protocol with type specs
Petr Viktorin added the comment: Yes, it should be possible to wrap them in #if so they aren't part of the stable ABI. -- ___ Python tracker <https://bugs.python.org/issue40724> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40802] AbstractEventLoop.shutdown_default_executor breaks backwards compatibility
New submission from Petr Viktorin : In bpo-34037, AbstractEventLoop gained a new abstract method, shutdown_default_executor: https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.loop.shutdown_default_executor All AbstractEventLoop subclasses need to define this method, otherwise they are not compatible with Python 3.9's asyncio. It seems that the anyio and uvloop projects are affected: https://github.com/agronholm/anyio/issues/110 This is mentioned in What's New: https://docs.python.org/dev/whatsnew/3.9.html#changes-in-the-python-api I'd like to make extra sure asyncio experts know about this backwards incompatibility. Since asyncio is no longer provisional, should it break backwards compatibility with just a What's New entry? -- components: asyncio messages: 370182 nosy: asvetlov, petr.viktorin, yselivanov priority: normal severity: normal status: open title: AbstractEventLoop.shutdown_default_executor breaks backwards compatibility versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue40802> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23897] Update Python 3 extension module porting guide
Petr Viktorin added the comment: py3c has an open issue to check that Barry's notes on C extensions are included: https://github.com/encukou/py3c/issues/1 However, C extensions are only a small part of the wiki page. -- ___ Python tracker <https://bugs.python.org/issue23897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40784] test_sqlite: CheckFuncDeterministic() fails with SQLite 3.32
Petr Viktorin added the comment: Indeed. The SQLite documentation talks about the limitations that non-deterministic functions have, not about deterministic functions being memoized: https://www.sqlite.org/deterministic.html The flag would be better tested e.g. with a CHECK constraint: https://www.sqlite.org/lang_createtable.html#ckconst -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue40784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type
Change by Petr Viktorin : -- pull_requests: +19690 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/20433 ___ Python tracker <https://bugs.python.org/issue40217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type
Petr Viktorin added the comment: Thank you for responding so quickly! > Petr, do you mind reviewing it? Yes, but I'll only get to it next week. -- ___ Python tracker <https://bugs.python.org/issue40217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type
Change by Petr Viktorin : Added file: https://bugs.python.org/file49182/reproducer.c ___ Python tracker <https://bugs.python.org/issue40217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type
Petr Viktorin added the comment: Ha! I think I found the issue in PySide now. It's different, but it's still a CPython issue. It's actually a variant of the "defining class" problem from PEP 573. It's legal to get the value of a slot, using PyType_GetSlot. It's reasonable to assume that what you put in the tp_traverse slot is what you'll get out using PyType_GetSlot. If a type's tp_traverse tries to call its superclass's tp_traverse, you can get an infinite loop. See the situation below or run attached reproducer (build the module, import it and exit the interpreter). Getting one's superclass is a bit tricky when dealing entirely with FromSpec types, but it is definitely *possible*. There's a lot of assumptions the code can reasonably make. In my reproducer, I stored the superclass in a C static variable (which is perfectly valid if the module cleanly refuses to work with subinterpreters or interpreter reload). Base: - real tp_traverse is PyType_FromSpec_tp_traverse - user_provided_tp_traverse is the base's original Subclass: - real tp_traverse is PyType_FromSpec_tp_traverse - user_provided_tp_traverse is the subclass' original So when the subclass is traversed: - subclass real tp_traverse calls the subclass user_provided_tp_traverse - subclass user_provided_tp_traverse calls PyType_GetSlot(base, tp_traverse) - that is, the base's real tp_traverse - the base's real tp_traverse calls the **SUBCLASS** user_provided_tp_traverse, since that's what's recorded in type(self) Another issue is that `PyType_FromSpec_Alloc`ated types lie about their size: `tp->tp_basicsize + Py_SIZE(self) * tp->itemsize` is not the actual allocated amount. This could technically be solved by redefining `__sizeof__`, but I'm more worried that it's another edge case of a hack, and There will probably be other edge cases. Since this is API we want to build on, I'd sleep easier if it's kept clean. What would be the downsides of reverting and documenting that tp_traverse must visit Py_TYPE(self)? It seems that you visit Py_TYPE(self), it could just end up with unbreakable reference cycles. We're dealing with modules and classes, which are usually effectively immortal (and if not, the author probably knows what they're doing). I don't think it would hurt that much. -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue40217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type
Petr Viktorin added the comment: Indeed, it seems my initial analysis was incorrect. I can't reproduce this outside of PySide. I'll close this bug and invesatigate more. Sorry for the noise. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40217] The garbage collector doesn't take in account that objects of heap allocated types hold a strong reference to their type
Petr Viktorin added the comment: It looks like the fix breaks types that override Py_tp_alloc but not Py_tp_traverse (as some types in PySide do.) I'll investigate more and work on fixing that if someone doesn't beat me to it. -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue40217> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38787] PEP 573: Module State Access from C Extension Methods
Change by Petr Viktorin : -- pull_requests: +19510 pull_request: https://github.com/python/cpython/pull/20215 ___ Python tracker <https://bugs.python.org/issue38787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38787] PEP 573: Module State Access from C Extension Methods
Petr Viktorin added the comment: I guess I'll need to clarify the documentation here. Call `PyType_GetModule` on the *defining class*, not on type(self). See the PEP for details. The associated module is not inherited; each class in the MRO can be defined in a different module. -- ___ Python tracker <https://bugs.python.org/issue38787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40601] [C API] Hide static types from the limited C API
Petr Viktorin added the comment:
> For example, Objects/longobject.c defines "PyTypeObject PyLong_Type =
> {...};". This type is exposed in the limited C API (!)
Technically, it is not, see https://www.python.org/dev/peps/pep-0384/#structures
Structures like PyLong_Type are *not* part of the limited API.
> I propose to break the limited C API backward compatibility on purpose by
> removing these type definitions form the limited C API.
That could only be done in Python 4.0, or if we started C-API 4.0. But I don't
think it's necessary here.
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue40601>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40574] segfault causing regression from PEP 573 implementation (PyQt5)
Petr Viktorin added the comment: So, the failure is expected. Python's ABI can change until the 3.9.0 final release, so wheels built for different commits can be incompatible. This applies to alphas/betas as well, as you say. There is the PEP 384 stable ABI, which is much stricter (and more limited), but sip doesn't use it -- its wheels are specific to cp36/cp37/cp38: https://pypi.org/project/sip/#files Thanks for testing, though! Perhaps we need to communicate better that for the alphas/betas, everything needs to be rebuilt. -- ___ Python tracker <https://bugs.python.org/issue40574> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40584] PyType_FromModuleAndSpec function should add the process of tp_vectorcall_offset
Petr Viktorin added the comment: That seems reasonable. See the discussion around https://bugs.python.org/issue38140 for context. Note that __dictoffset__ and __weaklistoffset__ are also exposed as members (in PyMemberDef type_members) and documented (Doc/c-api/structures.rst). A new __vectorcalloffset__ should have that as well. -- ___ Python tracker <https://bugs.python.org/issue40584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38787] PEP 573: Module State Access from C Extension Methods
Change by Petr Viktorin : -- pull_requests: +19251 pull_request: https://github.com/python/cpython/pull/19936 ___ Python tracker <https://bugs.python.org/issue38787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40246] Different error messages for same error - invalid string prefixes
Petr Viktorin added the comment: reportlab reported failures on code like: norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n') Note that `or` has a `r` in it. -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue40246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38787] PEP 573: Module State Access from C Extension Methods
Petr Viktorin added the comment: I'm working on the implementation as my time allows, here: https://github.com/encukou/cpython/pull/3 . Would it help to create a proper PR for CPython now? That would mean I could no longer do rebases/force-pushes, so the commits would be less readable. But happy to do it if it would help you. -- ___ Python tracker <https://bugs.python.org/issue38787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34037] asyncio: BaseEventLoop.close() shutdowns the executor without waiting causing leak of dangling threads
Petr Viktorin added the comment: I got a report from a library that ties together asyncio and some other async libraries, getting errors like this: tests/test_taskgroups.py:60: in test_run_natively module.run(testfunc()) /usr/lib64/python3.9/asyncio/runners.py:48: in run loop.run_until_complete(loop.shutdown_default_executor()) uvloop/loop.pyx:1451: in uvloop.loop.Loop.run_until_complete ??? /usr/lib64/python3.9/asyncio/events.py:254: in shutdown_default_executor raise NotImplementedError E NotImplementedError (more at: https://bugzilla.redhat.com/show_bug.cgi?id=1817681#c1 ) I'm not all that familiar with asyncio, but it seems to me that all event loops inherited from BaseEventLoop must be updated to implement this new method to correctly work with run() in Python 3.9. Is that right? If it is, this needs at least a much more prominent What's New entry. Or the hard NotImplementedError should turn into a warning. -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue34037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Change by Petr Viktorin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()
Petr Viktorin added the comment:
As discussed briefly in Mark's PR, benchmarks like this are now slower:
ret = dict(**{'a': 2, 'b': 4, 'c': 6, 'd': 8})
Python 3.8: Mean +- std dev: 281 ns +- 9 ns
master: Mean +- std dev: 456 ns +- 14 ns
--
___
Python tracker
<https://bugs.python.org/issue37207>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()
Petr Viktorin added the comment: > Can I submit the patch? Yes! If you think a patch is ready for review, just submit it. There's not much we can comment on before we see the code :) (I hope that doesn't contradict what your mentor says...) -- ___ Python tracker <https://bugs.python.org/issue37207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()
Petr Viktorin added the comment: Definitely! -- ___ Python tracker <https://bugs.python.org/issue37207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()
Petr Viktorin added the comment: The change to dict() was not covered by the smaller PRs. That one will need more thought, but AFAIK it wasn't yet rejected. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue37207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Petr Viktorin added the comment: Moved to Discourse, IMO that's a better place for maintainers of other PEP-3118-compatible libraries to chime in: https://discuss.python.org/t/behavior-of-struct-format-native-bool/3774 -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Petr Viktorin added the comment: I see. Thanks for your patience explaining this to me! I will merge and continue in a different issue. -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Petr Viktorin added the comment: I think we are speaking past each other. In my (current) view, the semantics are spelled out in the documentation: "any non-zero value will be True when unpacking". There's also a mention that this corresponds to the _Bool type in C. While this was the case with compilers in the past, it's no longer true with clang 9. In your view, the semantics are dictated by the correspondence to _Bool, and the "non-zero value will be True when unpacking" is the fluff to be ignored and removed. The docs assume the two behaviors (_Bool and non-zero) are equivalent. In this bug we find out that they are not, so to fix the bug, we need to make a choice which one to keep and which one to throw out. I see nothing that would make one view inherently better than the other. What "array libraries expect" is IMO not relevant: under any of the two views, libraries that are well-written (under that view) will be fine. Problems come when the library and Python choose different sides, e.g. when a non-C library can't use _Bool and thus packs arrays with the expectation that "any non-zero value will be True when unpacking". What is a minimal change in *implementation* is a bigger change in *behavior*: unpacking of arrays will now depend greatly on details like the compiler used to build Python. I see that as the greater evil: since the data can be sharted across environments, languages and compilers, keeping the semantics well-defined seems better than leaving them to the compiler. I don't see a compelling reason to choose _Bool semantics, but perhaps there is one. -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Petr Viktorin added the comment: > You are the one who wanted to *introduce* a hack by dereferencing as char and then cast to _Bool. :-) Yes, I did change my mind after reading the documentation. The docs say two contradicting things: 1. The '?' conversion code corresponds to the _Bool type defined by C99 2. ... any non-zero value will be True when unpacking. So it's clear that something has to change. IMO, preserving (2) and relaxing (1) is the more useful choice. -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Petr Viktorin added the comment: > The docs for native mode (we now always assume C99): > > "The '?' conversion code corresponds to the _Bool type defined by C99." But, nowhere is it suggested that conversion is "do memcpy and then interpret the bit pattern". That is pretty weird way to convert values in C; it seems to me that it's only a hack to avoid unaligned access. IMO, casting is a more natural way to convert values. And casting to _Bool coerces the value to 0 or 1. -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace
Change by Petr Viktorin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Petr Viktorin added the comment: > So I vote for not handling incorrectly packed values and removing "and any non-zero value will be True when unpacking" from the docs, which does not seem to make any sense for _Bool. I disagree. I don't think struct module's job is to be faithful to _Bool semantics. Up to this point, "?" worked for bytes with "only 0 is false" semantics, in a reliable and documented way. I don't see a reason to let that continue. You're right about trap representations, but IMO floats are much more tied to hardware (and serious users of float are aware of the pitfalls), while _Bool semantics are governed by the whims of the compiler. Also, the "@" prefix is specifically documented to select native Byte order, Size, and Alignment; not how the bit-pattern is interpreted. -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38076] Make struct module PEP-384 compatible
Change by Petr Viktorin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Petr Viktorin added the comment: Oh! I just reead the docs more carefully; they say: For the '?' format character, the return value is either True or False. When packing, the truth value of the argument object is used. Either 0 or 1 in the native or standard bool representation will be packed, and any non-zero value will be True when unpacking. -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Petr Viktorin added the comment: > > > maybe we should be raising an error if the bytes are not a valid platform > > > _Bool pattern? > > > > That's quite hard to test for. > > How so? We just make the same assumption you're making that true = b'\x01' > and false = NUL. Right, with that assumption, it's not that hard. And it becomes a test-only assumption, which is great! But, I'm still not convinced this would be a good fix. The current struct documentation is consistent with *casting* char to _Bool, rather than doing the memcpy and reinterpreting as _Bool. The memcpy makes sense for larget types, but not so much for _Bool. (Certainly, the docs' assertion that "the conversion between C and Python values should be obvious given their types" is not true here...) -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] struct and memoryview tests rely on undefined behavior (as revealed by clang 9)
Petr Viktorin added the comment: The memoryview module does the same thing as struct, and its tests expect the same behavior as with struct. So, whatever we do in struct should be also done in memoryview. -- title: test_struct failure on s390x Fedora Clang buildbot -> struct and memoryview tests rely on undefined behavior (as revealed by clang 9) ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37207] Use PEP 590 vectorcall to speed up calls to range(), list() and dict()
Change by Petr Viktorin : -- nosy: +petr.viktorin nosy_count: 4.0 -> 5.0 pull_requests: +18280 pull_request: https://github.com/python/cpython/pull/18928 ___ Python tracker <https://bugs.python.org/issue37207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] test_struct failure on s390x Fedora Clang buildbot
Change by Petr Viktorin : -- keywords: +patch pull_requests: +18277 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/18925 ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] test_struct failure on s390x Fedora Clang buildbot
Petr Viktorin added the comment: > our unittest assuming that b'\xf0' should be true when interpreted as a bool > is wrong. > just get rid of that value from the loop in the test? That could be the proper thing to do, but it does make it easy to invoke C undefined behavior from Python code. AFAIK, it would be the only such place in the struct module. So, I'd like to assume and assert/test that sizeof(_Bool) is 1 and the false bit-pattern is (char)0, and with that, just use `PyBool_FromLong((_Bool)*p != 0)`. > maybe we should be raising an error if the bytes are not a valid platform > _Bool pattern? That's quite hard to test for. Also, on all current supported platforms, the patterns for bool and char 0 and 1 are the same. I don't see this being different elsewhere, but if there ever is a such a platform, let the test catch the broken assumption. -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38960] DTrace FreeBSD build fix
Petr Viktorin added the comment: New changeset 3c97e1e457033bbb8bbe0b7198bd13fc794a12b0 by Petr Viktorin in branch 'master': bpo-39761: Fix dtrace build with empty $DFLAGS (GH-18766) https://github.com/python/cpython/commit/3c97e1e457033bbb8bbe0b7198bd13fc794a12b0 -- ___ Python tracker <https://bugs.python.org/issue38960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace
Petr Viktorin added the comment: New changeset 3c97e1e457033bbb8bbe0b7198bd13fc794a12b0 by Petr Viktorin in branch 'master': bpo-39761: Fix dtrace build with empty $DFLAGS (GH-18766) https://github.com/python/cpython/commit/3c97e1e457033bbb8bbe0b7198bd13fc794a12b0 -- ___ Python tracker <https://bugs.python.org/issue39761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39824] Multi-phase extension module (PEP 489): don't call m_traverse, m_clear nor m_free before the module state is allocated
Petr Viktorin added the comment: If you use a module subclass that needs some additional C-level infrastructure, it would be more appropriate to override tp_clear/tp_free directly. IMO limiting m_clear/m_free to work just with the module state won't hurt. But it is an API change. -- ___ Python tracker <https://bugs.python.org/issue39824> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39762] PyLong_AS_LONG missing from longobject.h
Petr Viktorin added the comment: No, in Python 2 the PyInt object (`int` in Python 2) always did fit into a C long -- that was the underlying storage. If it didn't fit, a PyLong object (`long` in Python 2) was used. Python 3 doesn't have PyInt, it only has PyLong (`int` in Python 3). -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue39762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] test_struct failure on s390x Fedora Clang buildbot
Petr Viktorin added the comment: Viewing the oss-fuzz bug requires login. Is there any interesting public info in it? -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39546] argparse: allow_abbrev=False is ignored for alternative prefix characters
Change by Petr Viktorin : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39546> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] test_struct failure on s390x Fedora Clang buildbot
Petr Viktorin added the comment: IMO: - The "native" format should use native _Bool, and we should only test unpacking 0 and 1 - The "standard" format should use portable char semantics: continue to treat any non-zero value as true - The docs should grow a warning that for the native format of '?', representation of true/false depends on the platform/compiler. But what is "format"? The docs talk about size, alignment and byte order; bool representation is a slightly different concept. I'm not sure if it should follow Byte order or Size/Alignment: I think that the latter would be better (so only "@" uses the native _Bool semantics, but "=" uses portable char semantics), but it might be be harder to implement. -- ___ Python tracker <https://bugs.python.org/issue39689> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39773] Export symbols for vectorcall
Petr Viktorin added the comment: Yes. Can you use PyObject_Call instead (or one of the non-Vectorcall variants listed in https://docs.python.org/3.9/c-api/call.html#object-calling-api ) Vectorcall is mainly a speed optimization over PyObject_Call. We want to allow the C compiler to inline PyObject_Vectorcall whenever it is used. That can be done with static functions or macros, which does unfortunately mean that the symbol is not exported. -- ___ Python tracker <https://bugs.python.org/issue39773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38960] DTrace FreeBSD build fix
Petr Viktorin added the comment: The fix introduced a regression, see bpo-39761 -- ___ Python tracker <https://bugs.python.org/issue38960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38960] DTrace FreeBSD build fix
Change by Petr Viktorin : -- pull_requests: +18123 pull_request: https://github.com/python/cpython/pull/18766 ___ Python tracker <https://bugs.python.org/issue38960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39761] Python 3.9.0a4 fails to build when configured with --with-dtrace
Change by Petr Viktorin : -- pull_requests: +18122 pull_request: https://github.com/python/cpython/pull/18766 ___ Python tracker <https://bugs.python.org/issue39761> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] test_struct failure on s390x Fedora Clang buildbot
Petr Viktorin added the comment:
C compiler dev that it's indeed undefined behavior.
> Quick and obvious fix:
>
> static PyObject *
> nu_bool(const char *p, const formatdef *f)
> {
> char x;
> memcpy((char *), p, sizeof x);
> return PyBool_FromLong(x != 0);
> }
>
> Which is optimized to
>
> static PyObject *
> nu_bool(const char *p, const formatdef *f)
> {
> return PyBool_FromLong(*p != 0);
> }
I'm left with a question for CPython's struct experts:
The above would be my preferred fix, but the Python code is asking to convert a
memory buffer to bool *using platform-specific semantics*.
Is this fix OK if C treats a \xf0 _Bool as falsey?
(Also, this assumes size of _Bool is the same as size of char.
I guess we can add a build-time assertion for that, and say we don't support
platforms where that's not the case.)
--
nosy: +mark.dickinson, meador.inge
___
Python tracker
<https://bugs.python.org/issue39689>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39689] test_struct failure on s390x Fedora Clang buildbot
Petr Viktorin added the comment:
The call:
struct.unpack('>?', b'\xf0')
means to unpack a "native bool", i.e. native size and alignment. Internally,
this does:
static PyObject *
nu_bool(const char *p, const formatdef *f)
{
_Bool x;
memcpy((char *), p, sizeof x);
return PyBool_FromLong(x != 0);
}
i.e., copies "sizeof x" (1 byte) of memory to a temporary buffer x, and then
treats that as _Bool.
While I don't have access to the C standard, I believe it says that assignment
of a true value to _Bool can coerce to a unique "true" value. It seems that if
a char doesn't have the exact bit pattern for true or false, casting to _Bool
is undefined behavior. Is that correct?
Clang 10 on s390x seems to take advantage of this: it probably only looks at
the last bit(s) so a _Bool with a bit pattern of 0xf0 turns out false.
But the tests assume that 0xf0 should unpack to True.
--
nosy: +petr.viktorin
___
Python tracker
<https://bugs.python.org/issue39689>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
Petr Viktorin added the comment: Why "sys.python_libdir"? Isn't that too public? A lot of similar path-related info is in sysconfig; why shouldn't it be there? How does "sys.python_libdir" work on other platforms? -- ___ Python tracker <https://bugs.python.org/issue1294959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39676] test_shutil fails with OSError: [Errno 28] No space left on device on "PPC64LE Fedora Stable LTO + PGO 3.x" buildbot
Petr Viktorin added the comment: Indeed, builds are green: https://buildbot.python.org/all/#/builders/449 Thanks Victor for reporting and Harris for fixing this. -- nosy: +petr.viktorin resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39676> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39555] test_distutils fails for Windows debug build
Petr Viktorin added the comment: New changeset d77e77116fa7a9fc85be1d9f417c7e9e33fe1296 by Miss Islington (bot) in branch '3.8': bpo-39555: Fix distutils test to handle _d suffix on Windows debug build (GH-18357) (GH-18548) https://github.com/python/cpython/commit/d77e77116fa7a9fc85be1d9f417c7e9e33fe1296 -- nosy: +petr.viktorin ___ Python tracker <https://bugs.python.org/issue39555> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39611] PyVectorcall_NARGS(): change return type to Py_ssize_t
Petr Viktorin added the comment: Closing; please reopen if we're somehow misunderstanding each other :) -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
